オープンソースリポジトリに貢献する

8 分

参加できる場所がわかったら、次の手順として投稿を準備します。ここでは、プロジェクトに参加する意思を伝え、pull request を作成し、それが受け入れられる可能性を高める方法について説明します。

オープンソースプロジェクトの作業に貢献しようとするときは、コミュニケーションが重要な成功要因になります。自分が提案した変更や改善について他の参加者とコミュニケーションを取ることに抵抗を感じるかもしれません。多くの場合、この対話は、自分の最初のビジョンに関するディスカッションや妥協案につながります。

オープンソースプロジェクトに参加している他の人々との活発なコミュニケーションを避けることは、他の誰かが既に作業しているタスクに時間をかけてしまう危険性があることを意味します。また、プロジェクトの価値やベストプラクティスに適合しない機能や改善の作業を行う危険性もあります。どちらの場合も、だれもが時間を無駄にすることになります。逆に、活発なコミュニケーションに時間をかけると、作業が歓迎され、大きな影響を与えるようになります。

新しい機能や変更について、他のプロジェクトメンバーとのコミュニケーションを確実に成功させるにはどうすればよいでしょうか? 第一に、心を開くようにしましょう。フィードバックを受け入れ、粘り強く対応します。ほとんどの場合、オープンソースプロジェクトの保守管理者は本業を持っているため、私生活にも配慮する必要があります。すぐに回答が得られなくても、保守管理者に催促する前に、もう少し待ってみましょう。

自分の意思を保守管理者に伝える

常に、実際に作業する前に、参加する意思があることを最初に伝える必要があります。 README で特に指定されていない限り、通常、それを行うのに最適な場所はイシュートラッカーです。

既存のイシューについて作業する場合は、[Assignees] (担当者) セクションを見て、そのイシューがだれにも割り当てられていないことを確認します。また、[Linked pull requests] (リンクされた pull request) セクションがないことを確認します。リンクされた pull request は、それについて既にだれかが作業中であることを意味します。コメントに目を通し、そのイシューの作業に関心があることを表明している人がいるかどうかを確認します。すべてを確認したら、イシューにコメントを投稿して、その作業に関心があることを表明します。このようにして、後で関心を持つ可能性のある人に、他の者が作業中であることを伝えます。また、必要に応じて、保守管理者からガイダンスやアドバイスを受けることもできます。
イシュートラッカーにまだ存在しない新しい機能やバグについて作業する場合は、新しいイシューを作成します。イシューテンプレートが提案されている場合は必ずそれに従い、そのイシューの作業を行う意思を明確に示します。新しい機能を提案する場合、またはイシューに多くの変更が必要な場合は、次のステップに進む前に必ず保守管理者の承認を得てください。

GitHub リポジトリで pull request を作成する

プロジェクトを支援する意思を伝えたら、実際の貢献に関する作業を開始できるようになります。

貢献には、pull request (PR) の形式を使用します。 pull request は GitHub 上の特別な場所で、次のものが含まれます。

変更のタイトルと説明。
提案されている変更を構成する 1 つ以上のコミット。
変更に関するディスカッションにだれでも参加できるコメント。
変更に関する詳細なフィードバックを確認し、最終的に提案をコミットできるコードレビュー。
たとえば、保守管理者によって設けられている可能性がある自動テストなどから得られる状態チェック。状態チェックは、さまざまな目的に使用できます。たとえば、変更がプロジェクトのルールに従っていることや、変更によってコードが破損していないことを確認できます。

作成された後の pull request は、新しいコミット、コメント、またはコードレビューで更新することができます。このプロセスは、プロジェクトの保守管理者が pull request を承認してマージするか、または変更を拒否して pull request を閉じるまで継続されます。 pull request がマージされると、変更がプロジェクトのコードベースに統合されたことを意味します。

pull request の作成手順

参加するプロジェクトの GitHub ページを開きます。
[Fork] (フォーク) ボタンを選択して、自分の GitHub アカウントでリポジトリのコピーを作成します。リポジトリが自分のコピーである場合を除いて、既定ではパブリックリポジトリで変更を行うためのアクセス許可がないため、このステップが必要になります。プロジェクトをフォークすると、変更できるコピーが作成されます。
アカウントプロファイルメニューから、[Your repositories] (ご使用のリポジトリ) を選択します。
リポジトリフォークを選択します。
[Code] (コード) ボタンを選択して、ローカルコンピューターに Git リポジトリを "クローン" する方法に関する情報を表示します。
クリップボード アイコンを選択してリポジトリの URL をコピーし、ターミナルで次のように入力します。
```
git clone <REPOSITORY_URL>
```
このコマンドにより、ローカルコンピューター上にリポジトリのコピーが作成されます。

別の方法として、アプリケーションを使用したい場合は、GitHub Desktop を使用できます。または、オプションが表示される場合は、GitHub Codespaces を使用できます。 Visual Studio Code ユーザーであれば、GitHub Codespaces は理解しやすいでしょう。
プロジェクトのクローンが完了したら、プロジェクトフォルダーに移動します。
```
cd <PROJECT_FOLDER>
```
(省略可能) 次のコマンドを使用して、新しいブランチを作成します。
```
git checkout -b <BRANCH_NAME>
```
このステップは必須ではありませんが、強くお勧めします。新しいブランチを使用すると、複数の貢献で異なるブランチを使用して個別に作業できます。
プロジェクトに対して必要な変更を行い、それらをコミットします。
```
git add .
git commit -m "<COMMIT_MESSAGE>"
```
これらのコマンドにより、コミットの変更がステージングされた後、指定されたメッセージを含むコミットが作成されます。コミットのメッセージでは、変更内容を正確に説明してください。また、コミットのメッセージで従う必要のある規則に関するメンションが CONTRIBUTING ファイルにあるかどうかを確認することをお勧めします。
次のコマンドを使用して、変更をリモート環境にプッシュします。
```
git push --set-upstream origin <BRANCH_NAME>
```
このコマンドを実行すると、GitHub (自分のフォーク) の上流リポジトリに新しいブランチが作成され、すべてのコミットがそれにプッシュされます。

Note

"上流" リポジトリとは、ローカルリポジトリにリンクされているリモートリポジトリのことです。 origin は、ステップ 4 で Git によって作成されたリポジトリの URL に対する既定の別名です。

前にブランチを作成していない場合は、「git push」だけを入力します。
GitHub でプロジェクトのフォークを開き、表示される提案ボックスの [Compare & pull request] (比較と pull request) ボタンを選択します。
タイトルと説明を入力し、[pull request の作成] を選択します。

pull request の説明用のテンプレートがある場合は、必要な情報をすべて入力します。それがない場合は、提案している変更の内容とその理由を保守管理者が理解するのに十分なコンテキストを必ず提供してください。また、#<ISSUE_NUMBER> を使用して番号をメンションすることにより、関連するイシューに戻るリンクも作成する必要があります。イシューの番号はタイトルの横で確認できます。

状態チェックに合格する

pull request を作成した後、次のような状態チェックを含むセクションが下部に表示される場合があります。

pull request の状態チェックの結果を示すスクリーンショット。

これらの状態チェックは、プロジェクトの一貫した品質を確保するために、保守管理者によって設けられている自動チェックです。

pull request が受け入れられるようにするには、すべての自動チェックに合格する必要があります。上のスクリーンショットのように不合格のものがある場合は、[Details] (詳細) ボタンを選択して、不合格の詳細を調べて、修正するために何が必要であるかを確認します。

不合格になったチェックの対処方法がわからない場合は、いつでもコメントを使用して、保守管理者にガイダンスや修正の支援を求めることができます。

pull request に関するガイダンスまたはレビューを要求する

行った変更について確信が持てず、保守管理者の見解が必要になる場合もあります。そのための最善の方法は、pull request に直接コメントすることです。変更が作業中であると考えられる場合は、他の共同作成者のガイダンスや支援を求める代わりに、"ドラフト pull request" を作成できます。

ドラフト pull request のオプションを示すスクリーンショット。

プロジェクトの保守管理者は、pull request を受け取った後、会話に返信したり、変更を直接レビューしたりすることができます。 pull request のレビューには、次のような複数の結果が考えられます。

変更が承認されます。お疲れさまでした。
pull request にはいくつかの変更が必要です。落胆することはありません。提供されたフィードバックを注意深く見てください。要求された変更を行えば、pull request が受け入れられる可能性は十分にあります。新しいコミットをブランチにプッシュすると、pull request は新しい変更で自動的に更新されます。
レビュー担当者がいくつかのコメントを作成しました。通常、それは、変更またはその背後にある動機について、さらに詳細な情報が必要であることを意味します。

pull request へのコメントに対応する

常にすべてのやり取りに敬意を払い、行動規範に従ってください。変更が受け入れられるようになるまでに、保守管理者や他の貢献者との継続的な話し合いが行われる可能性があります。

オープンソースに貢献するには忍耐が必要です。すぐにフィードバックを得られない場合があります。少しでも早く回答を得ようとして、メール、X、または他の手段で保守管理者に個人的に連絡を取らないでください。この行動は、よい結果をもたらさないと考えられます。公開でディスカッションをすることにより、他の共同作成者や通りすがりの人に、変更の背後にあるプロセスや従うべきベストプラクティスについて知る機会が与えられます。

続行

オープンソース リポジトリに貢献する