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

まず、プロジェクトで作業しており、すでにmasterブランチにいくつかのコミットがあるとしましょう。

会社が使用している課題追跡システムで、課題 #53 に取り組むことを決めたとします。新しいブランチを作成し、同時にそのブランチに切り替えるには、git checkoutコマンドに-bオプションを付けて実行します。

これは以下の省略形です。

ウェブサイトで作業を行い、いくつかのコミットをします。そうすると、iss53ブランチがチェックアウトされている（つまり、HEADがそれを指している）ため、ブランチが先に進みます。

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

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

この時点で、プロジェクトの作業ディレクトリは、課題 #53 に取り組む前とまったく同じ状態になり、ホットフィックスに集中できます。これは覚えておくべき重要な点です。ブランチを切り替えると、Gitは作業ディレクトリを、そのブランチに最後にコミットしたときの状態に戻します。Gitはファイルを自動的に追加、削除、変更して、作業コピーがそのブランチへの最後のコミット時の状態であることを保証します。

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

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

このマージで「fast-forward」（早送り）というフレーズに気づくでしょう。マージしたhotfixブランチが指すコミットC4が、現在いるコミットC2の真に先行していたため、Gitは単にポインタを先に進めるだけです。別の言い方をすると、あるコミットを、そのコミットの履歴を辿ることで到達できる別のコミットとマージしようとするとき、マージすべき分岐した作業がないため、Gitはポインタを先に進めることで処理を簡素化します。これを「fast-forward（早送り）」と呼びます。

これであなたの変更は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つのスナップショットと、それらの共通の祖先を使用して、単純な3方向マージを行います。

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

これで作業がマージされたので、iss53ブランチはもう必要ありません。課題追跡システムで課題を閉じ、ブランチを削除できます。

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

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

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

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

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

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

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

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

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

将来このマージを見る他の人にとって役立つと思われる場合は、このコミットメッセージを、マージをどのように解決したかについての詳細で修正し、行った変更が明らかでない場合はその理由を説明することができます。