株式会社シベスピ 従業員ブログ

シベスピの社員ブログ。技術・想い・経験沢山書いていきます!

バージョン管理システム"Git"はじめの一歩【後編】

さて、それでは後編です。前編では、gitの基本的な部分について説明いたしましたね。commit、push、pull、clone・・・それぞれ違いは理解できましたか?

後編では、ブランチについて説明し、最後に例を出して理解を深めます。

ブランチという考え

gitにはブランチといわれる機能が備わっています。そのブランチとは何なのか、何のためにあるのかを説明していきます。
f:id:chivsp:20200903210908p:plain

ブランチとは更新履歴の流れを分岐して記録することができる機能です。

複数人で作業している場合、Aさんは新機能の追加、Bさんはバグ修正・・・という風に担当が決まっているものです。

そういったときにみんなが毎回毎回すでに稼働が確認されているリリース版で作業を行うと、バグが起きたときに大変です。
修正するのに時間がかかってしまいますし、なによりリリース版が一旦停止してしまうというとんでもない事態になりかねません。

そこで、リリース版以外にも(木の枝のように)ブランチを作成し、分岐して作業を行います。
f:id:chivsp:20200903210950p:plain
ブランチには2種類のブランチがあります。統合ブランチとトピックブランチです。

統合ブランチ

f:id:chivsp:20200903211023p:plain
統合ブランチは「いつでも動作ができる、実行できる」状態にしておくブランチです。先ほどの説明で言いますと、リリース版です。
このブランチは1人1人の作業が終了したものがマージされてきます。
このブランチでバグが起きることはないようにしなくてはなりません。

基本的に動作の確認ができたもののみがマージされます。
作業途中のものや、まだバグが取り除かれていないものはマージされません。

トピックブランチ

f:id:chivsp:20200903211406p:plain
トピックブランチは担当者だけが使うブランチです。
追加機能班なら、追加機能ブランチを作成し、それにどんどん変更履歴を保存していきます。バグ修正班なら、バグ修正ブランチを作成し、それに変更履歴を保存していきます。

このトピックブランチは、細かな編集をするときに利用されることが多いので、動作が確認できなくても大丈夫です。

トピックブランチのトピックが完了次第、統合ブランチに統合していきます。
バグ修正が完全に完了したら、統合ブランチに統合しましょう。もちろん正しく動くかどうかは確認が必要です。

ブランチの切り替え(checkout操作)

ブランチとは木の枝のようにそれぞれの用途に合わせて作成し、それぞれの変更履歴を保存していくという機能でした。

ここで、例えばAさんはとても優秀な人で、機能追加とバグ修正の2つを担当しているとしましょう。

Aさんは「バグ修正が完了したので、機能追加に取り掛かろう」となるわけです。しかし、自分のローカルリポジトリにはバグ修正が完了した状態のディレクトリなので、このディレクトリ上で機能追加を行ってはいけません。なぜなら、Aさんは今“バグ修正”のブランチにいるのです。

そこでAさんは「機能追加のブランチに行かなくちゃ」となります。
ブランチを切り替える操作はcheckout操作です。
f:id:chivsp:20200903211238p:plain
またまた図の中に新たな言葉が出てたので説明します。

HEAD

gitの世界でHEADは「今いるブランチの最新の場所」を意味します。
今回の場合Aさんはバグ修正が完了したところなので、HEADはバグ修正ブランチの先頭にいます。

以上の説明、いかがでしょうか。
なんとなく、gitの使い方がみえてきたのではないでしょうか?
逆に、まだ曖昧な部分がある気がすると思った方もいるかもしれません。

最後に、mergeとブランチ、追加でrebaseについて例を出して説明し、理解を深めてもらえればと思います。
今までの復習と思って見てください。

例を出して理解を深める

さて、あなたは今、下図のAさんとします。
Aさんはtopic-branchの先頭(HEAD)にいます。
f:id:chivsp:20200903211506p:plain
Aさんは自分の作業が完了し、masterブランチ(以下master)へのマージを試みています。
しかし、masterにいきなりmergeをしたら、コンフリクトが発生してしまうかもしれません。

そこでAさんは一旦topic-branchにmasterの変更履歴をmergeしようと考えました。

ここで行うのがmerge操作でしたね。(コマンドは git merge master(コマンドって何?って人は気にしないで大丈夫です。))
f:id:chivsp:20200903211558p:plain

さあ!Aさんはmerge操作が完了し、コンフリクトも解消できました。いよいよ、Aさんはmasterにmerge操作を行うことができます。
しかし、Aさんはまだtopic-branchにいるので、このままではmasterにtopic-branchの変更履歴をmergeすることができません。

Aさんはmasterへとブランチを切り替える必要があります。
f:id:chivsp:20200903211651p:plain
ここで行われるのがcheckout操作です。(コマンドはgit checkout master)
f:id:chivsp:20200903211712p:plain
ようやくこれでAさんはmasterに移動することができました。
それではtopic-branchをmasterにmergeしましょう。
f:id:chivsp:20200903213103p:plain
以上でmasterにtopic-branchをmergeすることができました!!

続いて、発展編「rebase操作」です。
これまで説明していないので、いきなり理解するのは難しいかもしれません。

最初の状態は先ほどと一緒です。
f:id:chivsp:20200903211753p:plain
Aさんはmasterにtopic-branchをマージしたいので、rebaseしようと考えました。

rebase操作をするとどうなるのか?
下記のようになります。
f:id:chivsp:20200903211818p:plain

なんと、ブランチが生える場所が変わってしまうのです!
こうすることで、mergeとほぼ同様の「masterの変更履歴の内容をtopic-branchに取り込む」ということができます。
もちろんコンフリクトは発生する可能性があるので、そちらは解消してあげましょう。

あとは、同じ操作です。masterにmergeするには、一度masterに移動する必要(checkout)があります。
f:id:chivsp:20200903211846p:plain
最後にmerge操作です。
f:id:chivsp:20200903211859p:plain

終わりに

以上でgitの概要(内容?)の説明は終わりました。
最後には例を挙げて説明したので、理解しやすかったのではないでしょうか?

もちろん、今回の内容でgitのすべてを解説できたわけではありません。
もっと様々なコマンド(fetch操作など)があり、解説しだすとキリがありません。
ここからは自分で調べて、詳しくなっていってほしいと思います。
私もまだまだ知らない部分が多いので知識をつけていきたいです。