コントリビューターガイド
最初の pull request を出荷する方法
初心者向け Issue を見つけてから、メンテナーがレビューできる pull request をマージしてもらうまでの最短で信頼できる道筋です。
ここから始める
出発点を選ぶ
今の状態に近いものを選び、下の同じフェーズを進みます。
完全な初心者
ツール、用語、ドキュメントだけの変更から始めます。安全な 1 ループを終えることが目標です。
初めての PR
小さく最近の Issue を選び、diff を絞ります。コーディング前に範囲を確認しましょう。
再挑戦する貢献者
このプレイブックをチェックリストとして使い、再現とテストに一番力を使いましょう。
フェーズ 0
基本ツールを入れる
リポジトリを clone し、ブランチを作り、プロジェクトのチェックを実行し、作業を push できるだけのローカルツールがあれば十分です。
git
Git は作業を記録し、メンテナーが何が変わったかを正確にレビューできるようにします。
git --versiongh
GitHub CLI は fork、clone、認証、pull request 作成をターミナルから進める助けになります。
gh auth login
gh repo fork OWNER/REPO --clone --remoteエディタ
リポジトリ全体を検索でき、フォーマッターを実行し、変更ファイルを明確に見せるエディタを使います。
code .フェーズ 1
適切な Issue を選ぶ
良い first issue は小さいだけではありません。新しく、理解でき、プロジェクトを保守している人がレビューできる必要があります。
-
担当を申し出る
対象 Issue を明確にし、範囲がまだ妥当か尋ねる短いコメントを残します。
-
ルールを読む
コードを変える前に CONTRIBUTING、README、開いている PR、テストコマンド、コードスタイルを読みます。
-
Fork + branch
自分のコピーを作り、main ではなくタスク名に沿ったブランチで作業します。
-
セットアップ + 再現
依存関係を入れ、問題を再現し、どのコマンドや画面で確認したかを記録します。
-
小さな diff を出す
必要最小限だけ変更します。ついでのリファクタ、依存更新、無関係な整形は避けます。
-
PR を開く
何を変え、どうテストし、どんな制限があるかを説明します。レビュアーの最初の確認を楽にします。
立ち止まるポイント
さらに時間を使う前の注意点
レビューできない pull request を無理に作るより、早めに止まる方がよいです。
- 文書化された手順に従ってもプロジェクトをローカルで動かせない。
- 修正にメンテナーの入力なしでプロダクト挙動を推測する必要がある。
- Issue が大きな機能、再設計、移行、アーキテクチャ判断を求めている。
- メンテナーが初回貢献者にその領域を触らないでほしいと述べている。
リファレンス
用語集
- Fork
- リポジトリのあなた用コピー。pull request を開く前に自分のブランチをここへ push します。
- Branch
- 移動可能な作業線です。変更をレビューしやすく保つため、Issue ごとに 1 ブランチを使います。
- Pull request
- あなたのブランチをプロジェクトリポジトリへレビュー、マージしてもらうための依頼です。
- Diff
- 無関係な掃除を含まず、Issue を解決する最小限の意味ある変更集合です。
- CONTRIBUTING
- セットアップ、スタイル、テスト、pull request の期待をまとめたプロジェクト固有のチェックリストです。
FAQ
初めての PR でよくある質問
メンテナーから 1 週間返信がない場合は？
現在の状況と直接的な質問を短く投稿します。それでも返信がない場合は、無期限に待たず別の Issue を選びましょう。
セットアップに失敗したら？
試したこと、正確なエラー、OS とツールのバージョンを含め、次のデバッグ手順を質問しましょう。
最初の PR はドキュメントだけでもよいですか？
リポジトリがドキュメント変更を歓迎しているなら可能です。明確なドキュメント、例、誤字、壊れたリンクの修正は正当な貢献です。