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ファイルを読み込むように構築されています。mboxファイルとは、1つ以上のメールメッセージを1つのテキストファイルに保存するための、シンプルでプレーンテキスト形式のものです。それは次のように見えます。

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

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

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

Commit情報はパッチを適用した人物と適用時刻を示しています。Author情報は、パッチを最初に作成した個人とその作成時刻です。

しかし、パッチがきれいに適用されないこともあります。おそらく、メインブランチがパッチの元になったブランチから大きく分岐しているか、パッチがまだ適用されていない別のパッチに依存しているかのどちらかでしょう。その場合、git amプロセスは失敗し、何をしたいか尋ねてきます。

このコマンドは、競合するマージやリベース操作と非常に似ており、問題のあるファイルに競合マーカーを配置します。この問題の解決方法は非常に似ています。ファイルを編集して競合を解決し、新しいファイルをステージングし、その後git am --resolvedを実行して次のパッチに進みます。

Gitに競合をもう少し賢く解決させたい場合は、-3オプションを渡すことができます。これにより、Gitは3-wayマージを試みます。このオプションはデフォルトではオンになっていません。なぜなら、パッチが基づいているとされているコミットがリポジトリにない場合、機能しないからです。そのコミットを持っている場合、つまりパッチがパブリックなコミットに基づいていた場合、-3オプションは競合するパッチの適用に関して通常はるかに賢明です。

この場合、-3オプションがなければパッチは競合と見なされていただろう。-3オプションが使われたため、パッチはきれいに適用された。

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

これにより、多数のパッチを保存している場合に便利です。そのパッチが何だったか覚えていない場合はまずパッチを表示できますし、すでに適用済みの場合は適用しないという選択もできます。

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

基本的なワークフローの一つは、すべての作業を単純に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」 — 提案された更新）、そしてメンテナンスのバックポートのためのmaintという4つの長期実行ブランチがあります。貢献者によって新しい作業が導入されると、メンテナーのリポジトリで、これまで説明したのと同様の方法でトピックブランチに集められます（並行して貢献された複雑な一連のトピックブランチの管理を参照）。この時点で、トピックは安全で消費可能かどうか、あるいはさらなる作業が必要かどうかを判断するために評価されます。安全であれば、nextにマージされ、そのブランチはプッシュアップされて、誰もが統合されたトピックを試せるようになります。

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

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

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

導入された作業をあるブランチから別のブランチへ移動させるもう一つの方法は、チェリーピックです。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でさらに詳しく説明します。