Ctrlk
官网GitHub
For the complete documentation index, see llms.txt. This page is also available as Markdown.

コードに貢献

コードへの貢献は、明確な問題から始まります。バグ修正の前に再現できることを確認し、機能追加の前にユーザーシナリオと期待される挙動を説明してください。範囲の大きい変更は、まず GitHub Issue または Discussion で方向性をすり合わせることをおすすめします。

从说明问题、最小改动、本地验证到提交评审和合并的贡献流程图
1回の貢献で解決するのは、明確な1つの問題だけにし、まずローカルで検証してからレビューに出してください。

始める前に

Cherry Studio リポジトリ

ソースコード、README、開発エントリ

GitHub Issues

バグ、機能提案、未解決の課題

貢献ガイド

ブランチ、テスト、署名、レビュー要件

行動規範

コミュニティ協力の境界線

取り組みやすいタスクは good first issue、help wanted と kind/bug というラベルから探せます。着手前に、Issue で担当予定を明記し、複数人の重複作業を避けてください。

どのブランチを選ぶか

ほとんどの現在の機能、修正、リファクタリング、最適化は main に送ります。Issue、メンテナの案内、または貢献ガイドで別の対象ブランチが指定されている場合は、その時点のプロジェクトの案内に従ってください。古いチュートリアルだけで判断しないでください。

古いチュートリアルで対象ブランチを判断しないでください。PR を作成する前に、リポジトリの現在の貢献ガイドと PR テンプレートをもう一度確認してください。ブランチ戦略が変わっている場合は、リポジトリ内の内容を基準にしてください。

コード貢献に適している場合

状況
推奨方法

安定して再現できる問題

まず最小限の修正と対応するチェックを提出する

境界が明確な小さな機能

要件と対象ブランチを先に確認してから実装を始める

データ移行、権限、またはアーキテクチャに関わる

まず Issue または Discussion で方針をすり合わせる

説明文やスクリーンショットの修正だけが必要

【ドキュメントの貢献】に進み、コード PR に混ぜないでください

1つの PR では、明確な1つの問題だけを解決してください。機能追加、リファクタリング、無関係な整形を同時に含めると、レビュー担当者はリスクを判断しにくく、ロールバックもしづらくなります。

提出の流れ

1

1. Fork してブランチを作成する

正しい対象ブランチから、範囲の明確な作業ブランチを作成してください。1つの PR は1つのテーマだけを解決し、ついでのリファクタリングや書式調整は混ぜないでください。

2

2. 開発環境を準備する

リポジトリの【Developer Guide】に従って指定された Node.js と pnpm のバージョンをインストールし、 pnpm installを実行してください。変更を始める前に、対象モジュールに関連する既存のチェックを実行し、ベースラインが使えることを確認してください。

3

3. 変更して検証する

バグ修正には、問題を再現できるテストを追加してください。新機能には、重要な経路と失敗シナリオをカバーしてください。提出前に、リポジトリで求められるフォーマット、静的チェック、テスト、ビルドチェックを実行してください。

4

4. コミットして署名する

コミットメッセージには変更の種類とモジュールを明記し、 git commit --signoff を使って DCO 署名を追加してください。署名は、この内容をプロジェクトのライセンスに従って提出する権利があることを示します。

5

5. PR を作成する

テンプレートに従って、変更前後、なぜこの方法を採用したのか、トレードオフと代替案、破壊的変更、検証方法、Release Note を記入してください。まだ議論が必要な変更は、まず Draft PR を作成してかまいません。

PR 提出後

新規貢献者の PR にはまず needs-ok-to-test が付き、自動テストはすぐには開始されません。リポジトリメンバーの確認後、 /ok-to-test を使ってパイプラインを開始します。Draft PR は通常のレビュー担当者が割り当てられず、自動テストもスキップされます。準備ができたら Ready for review に切り替えてください。

レビューコメントは、新しいコミットで修正して、議論の文脈を維持してください。設計上の意見の相違が起きたら、まずユーザーの問題と検証可能な挙動に立ち返り、局所的な問題を避けるために大幅な書き換えをしないでください。

提出前のセルフチェック

  • 対象ブランチは正しいか；

  • 変更範囲は Issue/PR の説明と一致しているか；

  • 新しい挙動にはテスト、または再現可能な手動検証手順があるか；

  • ユーザーに見える変更はドキュメントも更新したか；

  • データ移行、アップグレード、互換性を考慮したか；

  • API キー、実際のユーザーデータ、デバッグファイルをコミットしていないか；

  • Commit は署名済みで、Release Note はテンプレート要件に合っているか。

小さな変更でも Issue は必要ですか？

スペルミスや明らかな小修正はそのまま提出して構いません。製品の挙動、アーキテクチャ、または比較的大きな作業が関わる場合は、先に Issue を立てたほうが方向性を確認しやすくなります。Issue が必要かどうかは、リポジトリの現在の運用ルールに従ってください。

なぜ CI が自動で実行されなかったのですか？

まず PR が Draft ではないことを確認してください。新規貢献者の PR には、リポジトリメンバーが /ok-to-test見たら needs-ok-to-test 、PR 内で気長に確認をお待ちください。

前へマルチウィンドウ研究ワークベンチ次へドキュメントに貢献

最終更新

役に立ちましたか？