Asial Blog

こんにちは！志田です。
最近ドラクエモンスターズを購入しました。
だいあくまの書・シュプリンガー・メッサーラのパーティでがんがんいってます。
配合を繰り返していると、「この組み合わせ、AにもBにもなるのに！どっちが強くなるんだろう？」ということがたびたび起こります。
そんなときに使えたらいいのが、今回ご説明するブランチです。

前回のあらすじ

前回の記事では、バージョン管理と基本的な動作について、ご説明しました。

・バージョン管理にgitを使おう！
・コミットを繰り返し、キリのいいところでプッシュする
・コミットを重ねることでバージョン管理ができる

こんな経験ありませんか

みなさん、これまでの経験で、こんな経験ってありませんか？

・直すことによる影響範囲が広いため、もしきちんと改修できて、テストもできたら安定バージョンに含めたい
　今まで何度もコミット・プッシュを重ねてきたプロジェクト。現在は安定バージョン！
　上司「ちょっとおっきめの改修、お願いするよ！」
　（えええ、それはちょっと、影響範囲が多岐に渡りますよ…）

・バグだらけでリリースしてしまったプログラム
　チケット（バグ管理の単位）ごとに修正して、直ったものから本番に含めたい

・とにかく、安定バージョンとバグ直し中のバージョンをごっちゃにしたくない！

コミットの流れと分岐

今までのコミットの流れは、こんなかんじです。
[コミット] → [コミット] → [コミット] →[現在の安定バージョン]
・・・これって、枝が伸びているように見えませんか？

それでは、さっき頼まれたあの改修を、現在のバージョンから枝分かれしたバージョンで行なって、
もしもきちんと修正・テストができたら現在のバージョンに含めるというのはどうでしょうか？
そうすれば、安定 + 修正のバージョンで、今以上によくなっているはず。

ブランチ

ひとつのプロジェクトから枝分かれをさせ、別の作業を行うことを「ブランチを切る」といいます。
ブランチとは、「支流、枝、分岐する」といった意味があります。
つまり、ブランチを切るというのは、「現行バージョンから枝分かれをさせる」という意味になります。

また、先ほどの図でいうと、安定バージョンを「masterブランチ」といいます。
これは、gitで管理をしている本流の、もともとのブランチのことで、自動的にmasterブランチと名前がついています。

ポケモンでいうと、サトシがイーブイゲットしたとき、もともとはサンダースにするつもりでした（masterブランチ）。
だけど、イーブイは1匹しかもらえないので、シャワーズとブースターも図鑑に書き加えたいです。
なので、masterブランチのほかに、シャワーズにしたバージョンとブースターにしたバージョンのブランチを切り、
あとでそれらをまとめれば、一気に全部の系統が図鑑に加えられます！やった！
ポケモンにもドラクエモンスターズにも美少女ゲームにも、ブランチが欲しいところですね。

プロジェクトでブランチ疑似体験

では、実際にやってみましょう。
まさとしさんは、自社のHPを作るプロジェクトを任されました。
まずは、git管理のプロジェクトを作成しました。

1. drwxr-xr-x   3 masatoshi  staff  102  6 13 18:29 .
2. drwx------+ 17 masatoshi  staff  578  6 13 18:28 ..
3. drwxr-xr-x  10 masatoshi  staff  340  6 13 18:29 .git

そして、そこにindex.htmlを作成しました。

1. ようこそ！アシアルのホームペーズへ！

index.htmlができました。うーん、我ながらいい出来。

1. drwxr-xr-x   4 masatoshi  staff  136  6 13 18:30 .
2. drwx------+ 17 masatoshi  staff  578  6 13 18:28 ..
3. drwxr-xr-x  10 masatoshi  staff  340  6 13 18:29 .git
4. -rw-r--r--   1 masatoshi  staff   55  6 13 18:30 index.html

index.htmlをgit addをして、git管理下に含めます。
そして、git commitをして、現在の状況をコミットしました。

1. $ git add index.html
2. $ git commit

コミットには、ひと目でなにがしたかわかりやすいようにコミットメッセージをつけます。

1. indexファイルを作成しました
2. # Please enter the commit message for your changes. Lines starting
3. # with '#' will be ignored, and an empty message aborts the commit.
4. #
5. # Committer: すくえに まさとし <masatoshi@example.com>
6. #
7. # On branch master
8. #
9. # Initial commit
10. #
11. # Changes to be committed:
12. #   (use "git rm --cached <file>..." to unstage)
13. #
14. # new file:   index.html
15. #

ひとまずこの状況を本番状態としました。



数日後、まさとしさんは上司に呼ばれました。
「まさとしくん、あのHPカッコイイんだけど、トップページ訛ってない？」

本当だ・・・

ホームページと打つつもりが、ホームペーズになっていました。うう、直したい。
それに、いい文章も思いついちゃったんだよな。追加したい…。

でも、本番はとりあえずバグなく動いているし、修正がちゃんとできてから、チェックをしてから本番に反映したい。
そうだ、ブランチを切ろう！

まさとし　ブランチを切る

とりあえず、現在のブランチを確認します。確認するには、git branchと入力します。

1. $ git branch
2. * master

git init した状態だと、masterというブランチができています。
これまでにご説明したとおり、本流のブランチになります。

では、ここからタイポ（打ちミス）を修正するためのブランチを作成します。
git branch <ブランチ名> と入力することで、ブランチを作ることができます。
作ったら、またgit branchコマンドで一覧を確認しましょう。

1. $ git branch typo
2. $ git branch
3. * master
4.   typo

ブランチの一覧を確認すると、たしかに「typo」ブランチができていることがわかります。
いままさとしさんが編集しているブランチはmasterで、行頭に*マークがついています。わかりやすいですね。

では、typoブランチに切り替えて、本当に切り替わったか確認します。
切り替えるには、git checkout <ブランチ名>と入力します。

1. $ git checkout typo
2. Switched to branch 'typo'
3. $ git branch
4.   master
5. * typo

*マークが移動し、ブランチがmasterからtypoに切り替わったことがわかります。



では、ファイルの中身を確認してみましょう。

1. ようこそ！アシアルのホームペーズへ！

特に変わっていません。
なぜなら、masterブランチからブランチを切ったために、masterブランチの状態（index.htmlがコミットされた状態）から
編集履歴が枝分かれしているだけだからです。
分かれた瞬間なので、なにも変わっていません。

では、タイポを直して行きましょう。
タイポを直すついでに、さっきひらめいた素敵なコピーも追加します。

1. ようこそ！アシアルのホームページへ！
2. PHPでの開発ならまかせてください！

修正したので、状態を見てみます。

1. $ git status
2. # On branch typo
3. # Changes not staged for commit:
4. #   (use "git add <file>..." to update what will be committed)
5. #   (use "git checkout -- <file>..." to discard changes in working directory)
6. #
7. # modified:   index.html
8. #
9. no changes added to commit (use "git add" and/or "git commit -a")

On branch typoとあることから、typoブランチでの修正であることがわかります。

では、gitの管理下に追加し、コミットしましょう。

1. $ git add index.html
2. $ git commit
3. typoの修正とコピーの追加
4. # Please enter the commit message for your changes. Lines starting
5. # with '#' will be ignored, and an empty message aborts the commit.
6. #
7. # Committer: すくえに まさとし <masatoshi@example.com>
8. #
9. # On branch typo
10. # Changes to be committed:
11. #   (use "git reset HEAD <file>..." to unstage)
12. #
13. # modified:   index.html
14. #

コミットはできましたが、今修正した内容が本番であるmasterブランチにも反映されてないかな？大丈夫かな？
まさとしさんを不安が襲いました。切り替えて確認してみます。

1. $ git checkout master
2. Switched to branch 'master'
3. $ vim index.html

・・・よかった！まだmasterブランチは訛ったトップページのままです。



では、先ほどのtypoブランチをmasterブランチにマージします。
ポケモンでいうと、イーブイをブースターにしたデータを、イーブイをサンダースにした本命データに統合して図鑑を埋めることです。

1. $ git merge typo
2. Updating 93fb5ae..2d7e002
3. Fast-forward
4.  index.html |    3 ++-
5.  1 files changed, 2 insertions(+), 1 deletions(-)

なにやら、index.htmlがマージされたようです。内容を確認しましょう。
おお！直っています！そのうえ、さっき追加した素敵なコピーも追加されています。やった！



では、もうこの「typo」ブランチは必要ないので、削除しましょう。
削除には、git branch -d <削除したいブランチ名> というように、-dのオプションをつけます。

1. $ git branch -d typo
2. Deleted branch typo (was 2d7e002).
3. $ git branch
4. * master

削除後に確認したところ、きちんとtypoブランチが削除され、元のmasterブランチだけになりました。
もちろん、先ほど行ったtypoブランチでの編集は、git mergeを行ったことでmasterブランチに含められたので、
typoブランチを消した今でも、masterブランチにその修正が残っているのです。

便利なブランチ

ブランチはいくつも作ることができます。
バグ単位で修正をしたり、大掛かりな修正をブランチとして切ったり、
Aブランチで行き詰まった時にBブランチを移動して、ブランチも頭も切り替えてすっきり作業するなど、
ブランチにはたくさんメリットがあります。

おさらい

・ブランチを切ると、本流とは別の作業ができる
・あるブランチの修正をしても、他のブランチに影響しない
・ブランチはバグ修正や、大掛かりな修正など本流をいじりたくないときに便利

ターミナル上で目に触れる「ブランチ」は、文字だし実体があるんだかないんだかといったところで
とっつきにくい部分がありますが、頭の中にコミットとブランチの枝を思い浮かべることで、
少しわかりやすくなるかと思います。

みなさんもブランチ切ってくださいね。