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形式でダウンロードした場合、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-wayマージを試みます。このオプションは、パッチが基づいていると主張するコミットがリポジトリに存在しない場合は機能しないため、デフォルトではオンになっていません。もしそのコミットを持っている場合 — パッチが公開コミットに基づいている場合 — -3オプションは、競合するパッチを適用する際に一般的にはるかに賢明です。

この場合、-3 オプションがなければ、パッチは競合と見なされていたでしょう。-3 オプションが使用されたため、パッチはクリーンに適用されました。

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

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

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

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

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

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

より重要なプロジェクトがある場合、二段階のマージサイクルを使用したいかもしれません。このシナリオでは、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 でより詳しく説明します。