大きな変更をする際の 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 担当者と話し合って、パブリッシュ前にマージが確実におこなわれるようにします。