git で merge 用のブランチを作る利点

master ブランチから大きく fork したトピック・ブランチを master へマージする時のお話。

小さな変更 (数日分) ならまだしも、数週間・数か月近くブランチが分岐したままだと、merge はどこかで conflict する。そこで力技に走っている人を見かけたので、アドバイスした。

merge 専用のブランチを作りなさいよ。

$ git branch
* big-change
  master

例えばこんな風に bag-change branch がある場合、直接、merge は行なわない (トラブルが起きないなら、直接 merge しても構わないと思うけど)。

$ git checkout master
$ git merge big-change

代わりに一回 merge 用の branch を作ってそこで conflict 解消の作業を進める。

$ git checkout master
$ git checkout -b merge-big-change
$ git merge big-change

こうしておけば、merge-big-change branch で取り返しの付かない失敗をしてもブランチを削除すればいいだけだし、master ブランチも big-change ブランチも綺麗なままなので、修正を加えることもできる。

一番好ましくないのは、conflict を起こして、その間 master も big-change ブランチもコンパイルが通らない (もしくはテストが通らない) 状況が続くこと。

意外と、こうやって「作業」を分割して、リスクを下げることに無頓着な人がいるのでエントリーにしてみた。まあ、それだけ git という VCS というか、ワークフローが磨かれて、泥臭い作業に直面する機会が減ったということなのかもしれない。