この記事は東北大学 計算機科学研究会 Advent Calendarの8日目の記事です。ブログと同時投稿です。

超入門したはいいけど次の修行がわからずに困っている人向けの記事です。決してアドベントカレンダーのネタが切れてつなぎで書いてるわけじゃないです

この記事を読んで得られること

  • ブランチとは何なのか
  • コンフリクトを恐れなくなる

ブランチとは?

ブランチというのは、パラレルワールドのようなものです。「もしこの変更ではなくこういう変更になっていたら」というように分岐させることができます。

例えば「この機能をつけてみたいけど、もしもコードがグチャグチャになって取り返しがつかなくなったらどうしよう…」と二の足を踏んだとき、ブランチを切ると安心して開発できます。「深刻なバグを生んでしまった」「コードがスパゲティとなってしまった」というときは元のブランチにすればOKです。

今、「スパゲティになったのなら直前のコミットに戻ればいいのでは?」と思ったあなたは鋭いです。実際、新機能を試していてスパゲティになったら直前のコミットに戻せば解決されます。新機能のために1度もコミットしていなければ。ブランチを切っておけば新機能を試しているときに何回もコミットすることが可能です。いざとなれば全部破棄でOKです。

ちなみに、いくつか前のコミットまで戻ることも可能ですが、そんなことするよりはブランチを切った方が安全で管理もしやすいです。

ブランチを作ってみる

実はリポジトリを作った時点で自動的にできるブランチがあります。masterブランチといいます。このブランチが大元のブランチとなっていきます。

今、試しにdevブランチを作ってみます。

$ git branch dev

devブランチに切り替えます。

$ git checkout dev

これでこれ以降のコミットはdevブランチへ行われるようになります。

マージする

新機能の開発のためにブランチを切って試作したとします。この試作がうまくいったのでmasterブランチにも新機能を追加したいとします。ブランチ同士をマージ(併合)することでこれを実現します。

実際にマージしてみましょう。

$ echo -n "Hello" > greeting.txt
$ git add .
$ git commit -m "create greeting"
$
$ git branch dev
$ git checkout dev
$
$ echo '' World" >> greeting.txt
$ git add .
$ git commit -m "hello world"
$
$ git checkout master
$ git merge dev

(見やすいように空行をはさみました。)1〜3行目でgreeting.txtを作りコミットします。5、6行目はdevブランチを作りブランチを切り替えます。8〜10行目でgreeting.txtに" World"と追記しコミットします(これが新機能の追加と思ってください)。最後にmasterブランチへ切り替えてdevブランチをmasterへマージしています。

うまくマージできるとmasterにdevで行った変更が適用されます。

コンフリクト

例えば先程の例でdevブランチをマージする前に、masterブランチのgreeting.txtを"Hello panda noir!"にしてみたらどうなるでしょうか?Gitはマージしようとしたとき、greeting.txtを「Hello World」にするべきか、「Hello panda noir!」にすべきか迷ってしまいます。迷ったGitは「僕はどっちがいいかわからないから、どっちにしたいか教えて」とプログラマに選択を投げます。「コンフリクト」の発生です。

コンフリクトの解消については他記事を参照ください(そのうち書きます)。

プルリク

実は世の中にはmasterブランチに直接コミットしないという文化が存在します。どういうことかというと、

  1. ブランチを切る
  2. そこで色々作業する
  3. コミットする
  4. masterへマージ

このような方法です。わざわざこんなことをする必要があるのは、複数人で開発するときです。実はこの流れはプルリクするときの流れです。つまり、直コミットを許可せず、全てプルリクにより開発するという手法です。

この方法は他の人からレビューを受けられるというメリットがあります。

逆に、個人開発の上では全く必要のない手順です。ただ面倒なだけです。