競合のあるマージ
さて、同一ファイルの修正があった場合、競合が起こってGitではマージできない場合があります。このような場合、Gitは警告を出し手動によるマージ操作を要求します。リスト7では、Program.csに競合があると警告が出ており、Program.csを参照すると、HEADとbugfixの間でマージができなかった部分にマークがついていることが確認できます。
$ git merge bugfix
Auto-merging Program.cs
CONFLICT (content): Merge conflict in Program.cs
Automatic merge failed; fix conflicts and then commit the result.
statemachine@mars /c/repository/sample (master *+|MERGING)
$ cat Program.cs
…中略…
namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
<<<<<<< HEAD
Init();
=======
Bugfix();
>>>>>>> bugfix
...省略...
このような場合、適材適所ということでツールの力を借りた方が、労力が少なくてすみます。Git Extensionsでは、最初からKDiff3によるマージツールが同梱されています。マージツールを起動するには、mergetoolオプションを利用します（リスト8）。
$ git mergetool
Merging:
Program.cs
Normal merge conflict for 'Program.cs':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
KDiff3の起動が促されるので、Enterキーを押すとツールが起動します（図11）。
上部左ペインから、共通の祖先、masterブランチ、bugfixブランチ、それぞれのファイルの内容が表示されます。競合の解決はそれらを参照しながら、下部ペインで行いますが、KDiff3の使い方については割愛します。
GUIでも同様にマージをすると、競合があった警告が表示され解決を促されます（図12）。デフォルトのマージツールはKDiff3であるため、［マージツールの開始］もしくは、［Open in kdiff3］のどちらかをクリックすれば、KDiff3が起動します。
競合を解決しコミットした状態は、以下のようになります（図13）。
まとめ
SVNユーザーにとって、Gitのブランチ概念は取っつきにくいかもしれません。trunckとbranchの作業フォルダは異なっているのが普通だからです。著者自身も、Gitの場合、ブランチの切り替えによって作業フォルダの内容が変わってしまう挙動に、最初は慣れませんでしたが、概念を理解することでそれらが払拭できた気がします。簡単なリポジトリを作成し、挙動を確認しながら理解していくのが習熟への近道かと思います。
