3.2 Gitブランチ - 基本的なブランチとマージ

まず、プロジェクトに取り組んでおり、`master`ブランチにいくつかのコミットがあるとします。

会社の課題管理システムで、課題番号53に取り組むことにしました。新しいブランチを作成して同時に切り替えるには、`-b`スイッチ付きの`git checkout`コマンドを実行します。

これは以下のコマンドの省略形です。

ウェブサイトで作業を行い、いくつかのコミットを行います。これにより、`iss53`ブランチが前進します。なぜなら、チェックアウトされている（つまり、`HEAD`がそれを指している）からです。

ウェブサイトに問題が発生し、すぐに修正する必要があるという連絡を受けたとします。Gitを使用すれば、行ったiss53の変更と一緒に修正プログラムをデプロイする必要がなく、修正プログラムを本番環境に適用する前にそれらの変更を元に戻すために多くの労力を費やす必要もありません。やるべきことは、masterブランチに切り替えるだけです。

ただし、その前に、作業ディレクトリまたはステージングエリアに、チェックアウトするブランチと競合するコミットされていない変更がある場合、Gitはブランチの切り替えを許可しません。ブランチを切り替える際には、クリーンな作業状態にするのが最善です。これを回避する方法（つまり、スタッシュとコミットの修正）については、後でスタッシュとクリーンアップで説明します。ここでは、すべての変更をコミット済みと仮定し、masterブランチに戻るとします。

この時点で、プロジェクトの作業ディレクトリは、問題＃53に取り組み始める前とまったく同じ状態になり、ホットフィックスに集中できます。これは重要な点です。ブランチを切り替えると、Gitは作業ディレクトリを、そのブランチに最後にコミットした時の状態にリセットします。ファイルの追加、削除、変更を自動的に行い、作業コピーが前回のコミット時のブランチの状態と一致するようにします。

次に、ホットフィックスを作成する必要があります。完了するまで作業するhotfixブランチを作成しましょう。

テストを実行し、ホットフィックスが意図したものであることを確認し、最後にgit mergeコマンドを使用してhotfixブランチをmasterブランチにマージして本番環境にデプロイします。

そのマージで「高速転送」というフレーズに気付くでしょう。マージしたhotfixブランチが指すコミットC4は、現在いるコミットC2の直接の先祖であったため、Gitは単にポインタを前方に移動します。言い換えると、あるコミットを、最初のコミットの履歴に従って到達できるコミットとマージしようとすると、Gitはマージする分岐した作業がないため、ポインタを前方に移動することで処理を簡素化します。これを「高速転送」と言います。

変更は、masterブランチが指すコミットのスナップショットに含まれるようになり、修正プログラムをデプロイできます。

非常に重要な修正プログラムをデプロイしたら、中断される前に実行していた作業に戻ることができます。ただし、最初にhotfixブランチは不要になったため（masterブランチが同じ場所を指しているため）、削除します。git branchに-dオプションを付けて削除できます。

これで、問題＃53の作業中のブランチに戻って作業を続けることができます。

ここで注意すべき点は、hotfixブランチで行った作業は、iss53ブランチのファイルに含まれていないことです。取り込む必要がある場合は、git merge masterを実行してmasterブランチをiss53ブランチにマージするか、後でiss53ブランチをmasterブランチにプルバックすることにするまで、これらの変更の統合を待つことができます。

問題＃53の作業が完了し、masterブランチにマージする準備ができたとします。そのためには、先ほどhotfixブランチをマージしたように、iss53ブランチをmasterブランチにマージします。やるべきことは、マージ先のブランチをチェックアウトし、git mergeコマンドを実行することだけです。

これは、先ほど行ったhotfixのマージとは少し異なります。この場合、開発履歴は以前のある時点から分岐しています。現在いるブランチのコミットがマージするブランチの直接の先祖ではないため、Gitは作業を行う必要があります。この場合、Gitは、ブランチの先端が指す2つのスナップショットと、その2つの共通の祖先を使用して、単純な3方向マージを実行します。

ブランチポインタを単純に前方に移動するのではなく、Gitはこの3方向マージの結果として新しいスナップショットを作成し、それを指す新しいコミットを自動的に作成します。これはマージコミットと呼ばれ、複数の親を持つ特殊なコミットです。

作業がマージされたので、iss53ブランチは不要になりました。問題追跡システムで問題を閉じ、ブランチを削除できます。

時々、このプロセスはスムーズに進みません。マージする2つのブランチで同じファイルの同じ部分を異なる方法で変更した場合、Gitはそれらをクリーンにマージできません。問題＃53の修正が、hotfixブランチと同じファイルの同じ部分を変更した場合、次のようなマージ競合が発生します。

Gitは新しいマージコミットを自動的に作成していません。競合を解決している間にプロセスを一時停止しています。マージ競合が発生した後に、どのファイルがマージされていないかを調べるには、git statusを実行できます。

マージ競合があり、解決されていないものはすべて、マージされていないものとしてリストされます。Gitは、競合のあるファイルに標準的な競合解決マーカーを追加するため、それらを手動で開き、競合を解決できます。ファイルには次のようなセクションが含まれています。

これは、HEAD（git mergeコマンドを実行したときにチェックアウトしていたmasterブランチ）のバージョンがそのブロックの上部（=======の上のすべて）であり、iss53ブランチのバージョンが下部のすべてであることを意味します。競合を解決するには、どちらか一方を選択するか、内容を自分でマージする必要があります。たとえば、この競合を次のように置き換えることで解決できます。

この解決策には各セクションの一部が含まれており、<<<<<<<、=======、>>>>>>>行は完全に削除されています。各競合ファイルのこれらのセクションをすべて解決したら、各ファイルに対してgit addを実行して、解決済みとしてマークします。ファイルをステージングすると、Gitで解決済みとしてマークされます。

グラフィカルツールを使用してこれらの問題を解決する場合は、git mergetoolを実行できます。これにより、適切なビジュアルマージツールが起動し、競合を案内します。

デフォルト以外のマージツールを使用する場合は（このコマンドはmacOSで実行されたため、Gitはopendiffを選択しました）、 「one of the following tools」の後にリストされているすべてのサポートされているツールを確認できます。代わりに使用したいツールの名前を入力するだけです。

マージツールを終了すると、Gitはマージが成功したかどうかを尋ねます。スクリプトに成功したことを伝えると、ファイルがステージングされて解決済みとしてマークされます。git statusを再度実行して、すべての競合が解決されたことを確認できます。

それで満足していて、競合があったものがすべてステージングされていることを確認したら、git commitと入力してマージコミットを確定できます。コミットメッセージはデフォルトで次のようになります。

将来このマージを見る人に役立つと思われる場合は、マージを解決した方法の詳細をこのコミットメッセージに追加し、変更が明らかでない場合は行った変更の説明を追加できます。