大きな変更をする際の GitHub コントリビューションワークフロー

概要

このワークフローは、大きな変更を加える必要があるコントリビューターや、リポジトリの使用頻度の高いコントリビューターに適しています。 頻度の高いコントリビューターは、通常は継続的な（長期にわたる）変更を取り扱います。つまり、構築／検証／ステージングのサイクルを繰り返したり、プルリクエストのサインオフや結合までに数日かかったりする変更を扱います。

用語

まず、このワークフローで使用される Git／GitHub の用語をいくつか確認しましょう。

Git および GitHub のリポジトリやブランチといった概念に馴染みがない場合は、Git および GitHub の基礎をまず確認してください。

ワークフロー

このワークフローでは、変更は反復的なサイクルとして実行されます。 変更は、使用しているデバイスのローカルリポジトリから、GitHub フォークに反映され、次にメインの GitHub リポジトリに反映されます。その後、再度ローカルに反映されて、他のコントリビューターの変更内容が統合されます。

GitHub フローの使用

Git および GitHub の基礎で説明したように、Git リポジトリには、main ブランチと、まだ main に統合されていない作業中のブランチが含まれています。 論理的に関連性のある一連の変更を導入するときは、このワークフローを通して変更を管理するための​ 作業ブランチ ​を作成することをお勧めします。 これを作業ブランチと呼ぶのは、main ブランチに統合できる状態になるまで変更の反復修正や手直しをするための作業用スペースとなるからです。

関連する変更を特定のブランチに隔離しておくと、これらの変更を独立して管理したり導入したりでき、公開サイクルの特定のリリースをターゲットにすることもできます。 おこなう作業の種類にもよりますが、実際の作業環境では、リポジトリ内に複数の作業ブランチができることがよくあります。 それぞれ別のプロジェクトの複数のブランチで同時に作業することも珍しくありません。

次に、ローカルリポジトリ内に新しい作業ブランチを作成し、ここで変更案を反映します。 Git クライアントによって作業方法が異なるので、使用するクライアントのヘルプを参照してください。 プロセスの概要については、GitHub ガイドの GitHub フローの説明を参照してください。

プルリクエストの処理

いくつかの変更案を新しいプルリクエスト（PR）にまとめて提出します。PR は、宛先リポジトリの PR キューに追加されます。 プルリクエストは GitHub の共同作業モデルを動かすための要素です。プルリクエストを使用して、作業ブランチから変更を取得し、別のブランチに結合するよう依頼することができます。 ほとんどの場合は、メインリポジトリ内のデフォルト／ main ブランチがマージ先になります。

検証

プルリクエストを宛先ブランチに結合する前に、1 つ以上の PR 検証プロセスを経なければならない場合があります。 検証プロセスは、変更案の範囲や宛先リポジトリのルールに応じて異なります。 プルリクエストを提出すると、そのコンテンツがレビューされ、適宜メインリポジトリに結合されます。

レビューとサインオフ

すべての PR 処理が完了したら、結果（PR コメント、プレビュー URL など）を確認する必要があります。 を使用して、結合のためにサインオフする前に、そのファイルに対する追加の変更が必要かどうかを判断します。 PR レビュー担当者がプルリクエストをレビューする場合は、結合前に解決すべき未処理の問題や質問があるときに、コメントでフィードバックが提供されることもあります。

プルリクエストが問題のない状態でサインオフされると、変更が親ブランチに結合されて、プルリクエストがクローズされます。

パブリッシュ

プルリクエストは、変更内容が次回の公開スケジュールに反映される前に、PR レビュアーによって結合される必要があります。 プルリクエストは、通常は提出された順序でレビューおよび結合されます。 特定のパブリッシュ実行にプルリクエストをマージする必要がある場合は、事前に PR 担当者と話し合って、パブリッシュ前にマージが確実におこなわれるようにします。