こんにちは、yutaです。
git系サービス(gitlabやgithub)って非常に便利何ですが、とっつきにくいのは否めませんよね。色々な機能がある中で、「ブランチって何？」と疑問を持つ方は多いのではないでしょうか。
本記事では、
・ブランチって何？使うメリットあるの？
という疑問にお答えします。
本記事では、ターミナルは一切使用しません。
1.「ブランチを作る」＝「別ユーザを作る」ということ！
2.実際にforkでブランチ作っていく。
3.各ブランチで編集。
4.チームで複数ファイルを扱う時に使える。
5.各ブランチでの編集内容をマージする。
1.「ブランチを作る」＝「別ユーザを作る」ということ！
早速ですが、「ブランチを作る」＝「別ユーザを作る」ということです。
ポケモンのようなRPGを色々なユーザが操作し、色々な場所でセーブしてゲームを進めていくように、ブランチを作ることでリポジトリ内を各ユーザが好きなように編集し保存することができます。
リポジトリ内の変更は、ユーザごとに別々で記録されているので、Aさんブランチで作業した内容がBさんのブランチに影響することは一切ありません。ポケモンで僕がどれだけコイキングを捕まえまくってもあなたのポケモンコレクションには一切影響がないですよね？なぜなら、操作しているユーザ(ブランチ)が違うからです。
ただし、各ブランチの変更内容を合わせる(マージする)時には変更点が重複しているとコンフリクトというエラーが起きるので注意が必要です。
口だけで説明してもなかなか分かりづらいと思うので、ここからは実際にforkでブランチを作って実践しながら解説します。
まだgit系サービスの登録やforkのインストールをしていない場合は、gitlabの登録からforkのインストール、gitlabとforkの連携〜コミット＆プッシュのやり方まで網羅した記事がありますので、そちらを参考にしてみてください。
【Git】forkの基本的な使い方【Gitlab】
2.実際にforkでブランチ作っていく。
とりあえず、testというリポジトリを作成して、その中に適当にファイルを作成します。今回は、テキストファイルで記事1、記事2を作成しました。
まずは初回コミットをしておきます。
次にブランチを作っていきます。
画面左側のBranchesを右クリックして、Create New Branchを選択します。
Branch nameに好きなブランチ名を入力してCreate and Checkoutをクリックします。今回はブランチ名をSatoshiとします。(Satoshiさん用のブランチ的な意味を込めて。)
同様にして、Hitomiという名前のブランチも作成します。
これでSatoshiとHitomiという名前のブランチを作成できました。
リポジトリを作成した時点でmasterというブランチが自動的に生成されるので、現在master、Satoshi、Hitomiの3つのブランチがあります。
以下の画像の通り、現在Hitomiにチェックが入っていますが、これは作業ブランチがHitomiブランチになっているという意味です。今、リポジトリ内のファイルを編集してコミットするとそれはHitomiブランチだけに反映されます。
3.各ブランチで編集。
これからリポジトリ内のファイルを編集していきます。
とりあえず、記事1.txtを以下のように編集してコミットします。
すると、forkのAll Commitsは以下のようになります。
Hitomiブランチでコミットしたので、それが表示されていますね。
ここで、Satoshiブランチに切り替えてみましょうか。
BranchesのSatoshiの上で右クリックして、Checkout ‘Satoshi’を選択するとブランチが切り替えられます。もしくは、Satoshiの上でダブルクリックでもOKです。
このように、Satoshiにチェックマークがついているので、現在の作業ブランチがSatoshiブランチに切り替わりました。
では、先ほど編集した記事1.txtを開いてみます。
白紙ですね。なぜなら、先ほどのHitomiブランチでの編集はSatoshiブランチに全く影響を与えないからです。
では、次は記事2.txtを開いて、以下のように編集してコミットしましょう。
コミットするとAll Commitsで以下のように表示されます。
masterブランチを起点にHitomiブランチでのコミットと、Satoshiブランチでのコミットが枝分かれしていますね。ブランチというのはまさにこのことです。
余談ですが、ブランチ(Branch)とは英語で「枝」という意味です。
もちろん、ここでHitomiブランチに切り替えても、Satoshiブランチでの編集は反映されていません。
masterを起点にHitomiさんとSatoshiさんが別々の人生を歩みだした、ということです。まさにポケモン。
したがって、Hitomiブランチでどれだけ編集しようが何しようが、Satoshiブランチには一切影響がないのです。逆も然りですね。
ただし、例えばSatoshiブランチで編集していた記事2.txtをHitomiブランチでも編集して、その変更を合わせようとする(マージする)と、コンフリクトが起きるので注意が必要です。
ブランチ機能を使えば各ブランチで自由に作業ができることはわかりましたが、ではこれは一体どういう時に使う意味があるんだ、という疑問が残っていますよね。
4.チームで複数ファイルを扱う時に使える。
ブランチが能力を発揮するのは、チームで複数ファイルを扱う時です。
例えば、チームでニュース記事を作成する時に、Hitomiさんは記事1を担当して、Satoshiさんは記事2を担当するみたいな話です。
では、実際にやってみましょう。
Hitomiブランチで以下のように編集&コミットします。
次にSatoshiブランチに切り替えて、以下のように編集&コミットします。
現在、各ブランチには、それぞれが編集した内容だけが反映されています。
ひとみさんは、ひとみさんの好きなタイミングで何回でもセーブポイントを作って(コミットして)、記事1を作っていき、さとしさんも同様にして記事2を作ります。
そして、最終的にお互いの記事が完成した段階で、片方の変更をもう片方に反映させます。これがマージです。
5.各ブランチでの編集内容をマージする。
4の最後の画像を見るとわかりますが、現在Satoshiブランチが選択されているので、SatoshiブランチにHitomiブランチでの変更をマージ(合わせる)していきます。
Hitomiブランチの最終コミットの上で右クリックして、Merge into ‘Satoshi’を選択します。
マージが完了すると、以下のようにHitomiブランチがSatoshiブランチと合体して1つの接点ができます。これは、Hitomiブランチでの変更内容がSatoshiブランチに反映されましたよ、という意味です。
Hitomiブランチには、Satoshiブランチでの変更内容が反映されないので注意です。
以下の通り、Hitomiブランチで編集した記事1の内容が、Satoshiブランチにも反映されています。つまり、Satoshiブランチには記事1と記事2両方の最新版があります。あとは、Satoshiブランチを担当しているさとしさんがお互いの記事をコピペして1つの記事を作ればお仕事終わりですね。
このようにブランチを作ることで、お互いのコミット履歴(編集履歴)を汚すことなく、同じリポジトリ内で作業ができます。そして、必要に応じてマージすることでお互いの最新版を自分のブランチに取り入れることができるのです。
実際には、アプリ開発などのプログラミング分野で利用されることが多いかと思いますので、今回の例は若干分かりづらかったかもしれませんが、少しでもブランチというものの理解に繋がれば幸いです。では、また！
ブログランキングに参加していますので、僕のモチベアップの為にもバナーを押していただけると嬉しいです！(※別タブで開きます)
