5.3 分散Git - プロジェクトの保守

git diffまたはUnixのdiffコマンドの何らかのバリエーション（推奨されません。次のセクションを参照）で生成されたパッチを誰かから受け取った場合は、git applyコマンドで適用できます。パッチを/tmp/patch-ruby-client.patchに保存したと仮定すると、次のようにパッチを適用できます。

これにより、作業ディレクトリ内のファイルが変更されます。これは、patch -p1コマンドを実行してパッチを適用するのとほぼ同じですが、patchよりも慎重で、ファジーマッチの許容度が低くなります。また、git diff形式で記述されていれば、ファイル追加、削除、名前変更を処理しますが、patchは処理しません。最後に、git applyは「すべて適用するか、すべて中止するか」モデルであり、すべてが適用されるか、何も適用されないかのいずれかですが、patchはパッチファイルを部分的に適用できるため、作業ディレクトリが奇妙な状態になる可能性があります。git applyは全体的にpatchよりもはるかに保守的です。コミットは作成されません。実行後、導入された変更を手動でステージングしてコミットする必要があります。

また、git applyを使用して、実際に適用する前にパッチがクリーンに適用されるかどうかを確認することもできます。パッチでgit apply --checkを実行できます。

出力がない場合、パッチはきれいに適用されるはずです。また、チェックが失敗した場合は、このコマンドは非ゼロのステータスで終了するため、必要に応じてスクリプトで使用できます。

コントリビューターがGitユーザーであり、format-patchコマンドを使用してパッチを生成してくれた場合、パッチには作者情報とコミットメッセージが含まれているため、作業が楽になります。可能であれば、コントリビューターにdiffではなくformat-patchを使用してパッチを生成するように促してください。git applyは、レガシーパッチやそのようなものに対してのみ使用する必要があります。

format-patchで生成されたパッチを適用するには、git amを使用します（コマンドは、「メールボックスから一連のパッチを適用する」ために使用されるため、amと命名されています）。技術的には、git amはmboxファイルを読み込むように構築されています。これは、1つ以上の電子メールメッセージを1つのテキストファイルに保存するための単純なプレーンテキスト形式です。次のようなものです。

これは前のセクションで見たgit format-patchコマンドの出力の始まりです。また、有効なmboxメール形式も表しています。git send-emailを使用して誰かが適切にパッチをメールで送信し、それをmbox形式でダウンロードした場合、git amにそのmboxファイルを指定すると、検出されたすべてのパッチの適用が開始されます。複数のメールをmbox形式で保存できるメールクライアントを実行している場合は、パッチシリーズ全体をファイルに保存し、git amを使用して1つずつ適用できます。

ただし、git format-patchで生成されたパッチファイルがチケットシステムなどにアップロードされた場合、ファイルをローカルに保存し、ディスクに保存したそのファイルをgit amに渡して適用できます。

きれいに適用され、自動的に新しいコミットが作成されたことがわかります。作者情報はメールのFromヘッダーとDateヘッダーから取得され、コミットのメッセージはメールのSubjectと本文（パッチの前）から取得されます。たとえば、このパッチが上記のmboxの例から適用された場合、生成されたコミットは次のようになります。

Commitの情報は、パッチを適用した人と適用された時間を示します。Authorの情報は、最初にパッチを作成した個人とそのパッチが最初に作成された時間を示します。

ただし、パッチがきれいに適用されない可能性があります。おそらく、メインブランチがパッチの作成元のブランチから大きく乖離しているか、パッチがまだ適用していない別のパッチに依存している可能性があります。その場合、git amプロセスは失敗し、どうしたいかを尋ねられます。

このコマンドは、コンフリクトが発生したマージやリベース操作のように、問題のあるファイルにコンフリクトマーカーを挿入します。この問題は、同様の方法で解決します。ファイルを編集してコンフリクトを解決し、新しいファイルをステージングしてから、git am --resolvedを実行して次のパッチに進みます。

Gitにコンフリクトをよりインテリジェントに解決させたい場合は、-3オプションを渡すことができます。これにより、Gitは3方向マージを試みます。パッチがベースにしていると記述されているコミットがリポジトリにない場合、このオプションは機能しないため、デフォルトではオンになっていません。そのコミットがある場合（パッチが公開コミットに基づいている場合）、-3オプションは通常、コンフリクトが発生しているパッチの適用に関してよりスマートになります。

この場合、-3オプションがないと、パッチはコンフリクトと見なされたでしょう。-3オプションを使用したため、パッチはきれいに適用されました。

mboxから多数のパッチを適用している場合は、インタラクティブモードでamコマンドを実行することもできます。これにより、検出された各パッチで停止し、適用するかどうかを尋ねられます。

多数のパッチを保存している場合に便利です。なぜなら、それが何かを覚えていない場合は最初にパッチを確認したり、すでに適用済みの場合はパッチを適用しないようにしたりできるからです。

トピックのすべてのパッチが適用され、ブランチにコミットされたら、それらをより長期実行されているブランチに統合するかどうかと、その方法を選択できます。

1つの基本的なワークフローは、すべての作業をmasterブランチに直接マージすることです。このシナリオでは、基本的に安定したコードを含むmasterブランチがあります。完了したと思うトピックブランチでの作業や、他の誰かがコントリビュートし、検証した作業がある場合は、それをmasterブランチにマージし、マージしたばかりのトピックブランチを削除して、繰り返します。

たとえば、複数のトピックブランチを持つ履歴のように見えるruby_clientとphp_clientという名前の2つのブランチで作業を行うリポジトリがあり、ruby_clientの後にphp_clientをマージすると、履歴はトピックブランチのマージ後のようになります。

これはおそらく最も簡単なワークフローですが、導入するものについて非常に注意する必要がある大規模またはより安定したプロジェクトを扱っている場合は、問題になる可能性があります。

より重要なプロジェクトがある場合は、2段階のマージサイクルを使用することをお勧めします。このシナリオでは、masterとdevelopの2つの長期実行ブランチがあり、masterは非常に安定したリリースがカットされた場合にのみ更新され、すべての新しいコードはdevelopブランチに統合されると判断します。これらの両方のブランチを定期的にパブリックリポジトリにプッシュします。マージする新しいトピックブランチがあるたび（トピックブランチのマージ前）、それをdevelopにマージします（トピックブランチのマージ後）。次に、リリースにタグを付けるときに、安定したdevelopブランチがある場所にmasterを早送りします（プロジェクトリリース後）。

このようにすることで、プロジェクトのリポジトリをクローンした人は、masterをチェックアウトして最新の安定版をビルドし、それを簡単に最新の状態に保つことができます。あるいは、より最先端のコンテンツであるdevelopをチェックアウトすることもできます。さらに、すべての作業がマージされるintegrateブランチを作成することで、この概念を拡張することもできます。そして、そのブランチ上のコードベースが安定し、テストに合格したら、それをdevelopブランチにマージします。それがしばらく安定していることが証明されたら、masterブランチを早送りします。

Gitプロジェクトには、master、next、および新規作業用のseen（以前は「pu」 - proposed updates）と、メンテナンスバックポート用のmaintの4つの長期実行ブランチがあります。コントリビューターによって新しい作業が導入されると、それらは、（並行して投稿されたトピックブランチの複雑なシリーズの管理を参照）で説明した方法と同様に、メンテナーのリポジトリのトピックブランチに収集されます。この時点で、トピックは、安全で消費の準備ができているか、またはさらに作業が必要かを判断するために評価されます。安全な場合は、nextにマージされ、そのブランチがプッシュアップされるため、誰もが統合されたトピックを試すことができます。

トピックがまだ作業を必要とする場合、それらは代わりにseenにマージされます。それらが完全に安定していると判断されたら、トピックはmasterに再度マージされます。その後、nextおよびseenブランチは、masterから再構築されます。これは、masterがほぼ常に前進し、nextが時々リベースされ、seenがさらに頻繁にリベースされることを意味します。

トピックブランチが最終的にmasterにマージされたら、リポジトリから削除されます。Gitプロジェクトには、メンテナンスリリースが必要な場合にバックポートされたパッチを提供するために、最後のリリースからフォークされたmaintブランチもあります。したがって、Gitリポジトリをクローンすると、開発のさまざまな段階でプロジェクトを評価するためにチェックアウトできる4つのブランチがあり、どれほど最先端にしたいか、またはどのように貢献したいかに応じています。また、メンテナーは新しい貢献を審査するのに役立つ構造化されたワークフローを持っています。Gitプロジェクトのワークフローは特殊化されています。これを明確に理解するには、Gitメンテナーガイドを確認できます。

他のメンテナーは、ほとんど線形の履歴を維持するために、コントリビュートされた作業をマージするのではなく、masterブランチの上にリベースまたはチェリーピックすることを好みます。トピックブランチに作業があり、それを統合したいと判断した場合は、そのブランチに移動し、リベースコマンドを実行して、現在のmaster（またはdevelopなど）ブランチの上に変更を再構築します。それがうまくいけば、masterブランチを早送りすることができ、線形のプロジェクト履歴になります。

導入された作業をあるブランチから別のブランチに移動するもう1つの方法は、チェリーピックすることです。Gitのチェリーピックは、単一のコミットのリベースのようなものです。コミットで導入されたパッチを取得し、現在いるブランチに再適用しようとします。これは、トピックブランチに多数のコミットがあり、そのうちの1つだけを統合したい場合、またはトピックブランチに1つのコミットしかなく、リベースを実行するよりもチェリーピックすることを好む場合に役立ちます。たとえば、次のようなプロジェクトがあるとします。

コミットe43a6をmasterブランチにプルしたい場合は、次を実行できます。

これにより、e43a6で導入されたのと同じ変更がプルされますが、適用日が異なるため、新しいコミットSHA-1値を取得します。これで、履歴は次のようになります。

これで、トピックブランチを削除し、プルしたくないコミットを削除できます。

多くのマージとリベースを行っている場合、または長期にわたるトピックブランチを維持している場合、Gitには「rerere」と呼ばれる便利な機能があります。

Rerereは「reuse recorded resolution（記録された解決策の再利用）」の略で、手動によるコンフリクト解決をショートカットする方法です。rerereが有効になっている場合、Gitは成功したマージの前後のイメージのセットを保持し、以前に修正したのとまったく同じようなコンフリクトがあることに気付いた場合、それを気にせずに前回の修正を単に使用します。

この機能は、構成設定とコマンドの2つの部分で構成されています。構成設定はrerere.enabledであり、グローバル構成に含めるのに十分便利です。

これで、コンフリクトを解決するマージを実行するたびに、将来必要になった場合に備えて、解決策がキャッシュに記録されます。

必要に応じて、git rerereコマンドを使用してrerereキャッシュとやり取りできます。単独で呼び出されると、Gitは解決策のデータベースをチェックし、現在のマージコンフリクトとの一致を見つけようとし、それらを解決しようとします（ただし、rerere.enabledがtrueに設定されている場合は、これは自動的に行われます）。また、記録される内容を確認したり、キャッシュから特定の解決策を消去したり、キャッシュ全体をクリアしたりするためのサブコマンドもあります。rerereの詳細については、Rerereで説明します。