裏紙に書く程度の内容

ブランチを切る - Git入門

Git入門の第5回目です。

今回はブランチについて勉強していきます。

ブランチは使わなくても何とかなるんですが、それではgitがただのバックアップツール程度の機能しか持たないことになります。
これではgitの機能の半分も使えておらず、もったいないです。

最初のうちはとっつきにくいかもしれませんが、実際に使い慣れると非常に便利な機能なので今のうちに慣れておきましょう。

目次はこちら

ブランチって?

そもそもブランチって何ぞや?というところから始めましょう。

ブランチ(branch)とは、日本語で「枝」という意味です。

以下の図を見てください。

ブランチとは

図中の”○”印はコミットした箇所と思ってください。

青い線は「マスターブランチ」或いは単に「マスター」と呼ばれ、今まではこの線上にいました。

そこから緑とオレンジの線に枝分かれしていますね。これが「ブランチ」です。
黒い矢印部、別のブランチを作成することを「ブランチを切る」といいます。

これらのブランチもマスターと同様、任意にコミットしていきます。
そして最後に、赤い矢印でマスターに戻っています。(これは「マージ」という作業)

各ブランチ上でのコミットではマスターには何の影響も与えません。

注目すべきは緑・オレンジ共に任意にコミットしています。この時、青(マスター)には何の影響も与えていません。

つまり、元になるソースコードはそのままに、別の作業を自由に進められるということです。

より実践的な例

ニュアンスとしては上図でわかるかと思います。では、実際の業務での使用例を挙げてみます。

前提として、既に稼働中のサービスについてです。時系列を追ってみてみましょう。

  1. マスター(青)での最終コミットがリリース済み。
  2. 2次開発として追加機能を作成することになったので、さっそくブランチ(オレンジ)を切って作業開始!
  3. おおっと!ユーザから連絡!バグが見つかった!!
  4. マスター(青)から別途ブランチ(緑)を切ってバグ修正。
  5. ブランチ(緑)上でなおったことを確認できたので、マスター(青)へ戻す(マージ)
  6. 追加機能ブランチ(オレンジ)に戻って作業を再開!
  7. 追加機能もできたのでマスター(青)へ戻す(マージ)

といった具合。

まあ、この程度ならgitがなくても何とか対処できますが、gitがあるとブランチ間の移動はコマンド一発なので非常に便利になります。

並行作業ができる

前述例もそうなんですが、ブランチを複数作るということは「=並行作業が出来る」ということです。

前述では「バグ修正」と「機能追加」が同時にできるということですね。

1人で使っている分にはピンとこないかもしれませんが、例えば「機能追加」はメイン作業者に、「バグ修正」は緊急なので助っ人超有能作業者にやってもらう、ということが出来ちゃいます。

このように、チームで開発する場合はブランチを切るのは必須とも言えるので今のうちに慣れておくといいでしょう。

ためしてみよう

ごたくはこのくらいにして、実際に使ってみましょう。

現在のブランチを見る

$ git branch
* master

git branchで存在しているブランチが閲覧できます。*マークは自分がどのブランチにいるかを現しています。

今のところ”master”ブランチしかないので* masterとなっていますね。

ブランチを切る

ではブランチを作ってみます。以下を実行してください。

$ git branch develop
$ git branch
  develop
* master

git branch [ブランチ名]で指定した名前のブランチが出来ます。但し、ブランチの「移動」はしません。
上記のとおり* masterとなり、自分はまだマスター上にいます。

ブランチを移動する

ブランチを移動するには以下のコマンド。

$ git checkout develop
Switched to branch 'develop'
$ git branch
* develop
  master

git checkout [ブランチ]で指定ブランチへ移動します。git branchで一覧を見ると確かに* developとなっていて、移動していることが確認できますね。

新しいブランチは、現在いるブランチ上の最終コミットの状態で作成されます。

ブランチ上で編集

では、’develop’ブランチにいる状態でファイルを適当に編集・コミットしてください。

$ git commit ./ -m 'branch test'
[develop 57ff153] branch test
 1 file changed, 2 insertions(+)

※ここでは-mオプションでコミットメッセージは1行のみにしました。複数行のコミットメッセージを書くには前回を参考にしてください。

コミット出来たら各ブランチの状態を確認してみます。

一旦マスターに戻ってみます。ブランチの移動はgit checkoutでしたね。

$ git checkout master
Switched to branch 'master'
$ git branch
  develop
* master

ここで、先程修正・コミットしたファイルを開いてみてください。

修正したはずの箇所がなかったことになっているのが確認できるかと思います。確かに、別ブランチ上の編集・コミットはmasterに影響を与えていないようですね。

では、もう一度developブランチに戻ってみましょう。

$ git checkout develop
Switched to branch 'develop'

そして、再度編集したファイルを開いて確認してください。

今度は先程の編集がされている状態になっているかと思います。

このように、ブランチを行ったり来たりできるようになると作業も整理しやすいですね。

マージする

で、忘れてはならないのがマージ。ブランチを統合する作業です。
最初のイメージでは赤い矢印になっている部分ですね。

今の例では “develop” ⇒ “master” に統合するのがいいですね。

さっそくコマンドを見ていきます。

$ git checkout master
Switched to branch 'master'
$ git merge --no-ff develop
Merge made by the 'recursive' strategy.
 test.txt | 2 ++
 1 file changed, 2 insertions(+)

一旦統合先のブランチ(ここでは’master’)に移動してからgit mergeコマンドを実行します。

この状態でもう一度編集したはずのファイルを開いてみると、developブランチでの編集が反映されているかと思います。

--no-ffというのは現段階では理解しておく必要はありません。「そういうもの」とだけ思っておいてください。

これで、一連の作業が完了です!!

要らないブランチを消す

ついでに不要になったブランチを消す方法。

$ git branch
  develop
* master

$ git branch -d develop
Deleted branch develop (was 57ff153).

$ git branch
* master

git branch -d [ブランチ名]で不要なブランチは削除できます。


編集がバッティングした場合は?

マージコマンドは非常に便利で、gitが勝手に差分を統合してくれます。

しかしながら、統合時に同一箇所に編集がある場合はそうはいきません。
(この状態を「コンフリクト」と呼びます)

各々ブランチで意図する修正を、どちらも生かした状態で統合する必要がありまが、これはさすがに自動で行うのは無理で、人の手で統合してやる必要が出てきます。

その作業方法は次回で!!

URABLO
広告
Index
広告