【初心者向け】Gitのブランチとは？「枝分かれ」の考え方をやさしく解説

こんにちは！
駆け出しエンジニアのまるです👓️🦍

前回の記事では、「Gitとは何か？」について触れていきました。

Gitは、簡単に言うと
変更履歴を記録できる仕組み
でしたね。

ゲームでいうと、セーブポイントのようなものを作って、あとからその時点の状態を見返したり、戻ったりできる。
そんなイメージでお話ししました。

そして今回は、Gitの中でもとても大切な考え方である
「ブランチ」
について解説していきたいと思います。

Gitを学び始めたときに、
・ブランチって何？
・なんでわざわざ分けるの？
・過去に戻ったら、今のデータはどうなるの？
と疑問に思う方はかなり多いです。

実際、僕も最初は
「セーブポイントに戻れるのはわかった。でも、そのあとってどうなるの？」
と、かなりモヤモヤしていました。

ですが、この「ブランチ」という考え方がわかるようになると、
Gitの理解が一気に進みます！

今回はできるだけむずかしい言葉を使わずに、やさしく解説していきます。

結論：ブランチとは「別ルートで安全に作業するための仕組み」

まず結論から言うと、
ブランチとは、大元の流れから枝分かれして別ルートで作業するための仕組みです。

「枝」と聞くと、実際に木の枝をイメージするとわかりやすいです。

幹が１本あって、そこから枝が分かれて行きますよね。
Gitのブランチもそれと同じで、もともとの流れから作業用の枝を作って、そこで変更を進めていくことができます。

つまり、
・大元のコードはそのまま残す
・別の場所で安心して作業する
・良さそうなら最後に大元へ取り込む
ということができるんです。

これが、Gitのブランチの大きな役割です。

過去に戻ったら、自動で枝ができるの？

ここで気になるのが、
「昔のセーブデータに戻ったら、そのまま別ルートになるの？」
というところだと思います。

この点は、少し注意が必要です。

結論としては、
過去のコミットに戻っただけで、自動的に新しいブランチができるわけではありません。

ここは誤解しやすいポイントです。

Gitでは、過去の履歴そのものは残っています。
なので、昔の状態を見たり、その時点を基準に作業したりすることはできます。

ただし、
別ルートとして開発を進めたい場合は、新しくブランチを作る必要があります。

つまり、
・過去の履歴は残る
・でも勝手に枝が増えるわけではない
・枝分かれさせたいなら、自分でブランチを作る
ということです

ここがわかると、Gitのブランチをかなり正しくイメージできるようになります。

ブランチはなぜ必要なの？

では、そもそもなぜブランチが必要なのでしょうか。

理由はシンプルで、
大元のコードを壊さずに安全に作業を進めるためです。

たとえば、すでに動いている大事なコードがあるとします。
そこにいきなり新しい機能を追加したり、見た目を修正したりすると、思わぬ不具合が起きることがあります。

そんなときに、大元のブランチとは別に作業用ブランチを作っておけば、
・新機能の追加
・バグ修正
・デザイン変更
などを、安心して試すことができます。

もし途中でうまくいかなくても、大元のコードには影響しません。

これがブランチのとても大きなメリットです。

ゲームでたとえると、ブランチは「育成ルート分岐」

ここまで呼んでも、まだ少しピンと来ない方もいるかもしれません。

なので、今回もゲームにたとえてみます！

たとえば、あなたが勇者を育てているとします。

魔王を倒すために、
・剣士として育てるのがよさそう
・魔法も使える勇者にしたい
・守備力重視で育てるのもありかもしれない

こんなふうに、いろいろなパターンを試したくなることってありますよね。

でも、セーブデータがひとつしかなかったらどうでしょうか。

剣士ルートを選んだら、
魔法戦士ルートは試しにくくなります。

そこで便利なのが、ブランチです。

ブランチを使えば、
同じスタート地点から、別々の育成ルートを試すことができるんです。

つまり、
・元の勇者データはそのまま残す
・別ルートで育成を試す
・いちばんよかったものを採用する
ということができるわけです。

Gitでもこれと同じで、
大元の状態を保ったまま、別の変更パターンを安全に試せるというのがブランチの強みです。

変更を大元に取り込める

ブランチの便利なところは、
ただ分けて作業できるだけではありません。

作業用ブランチで進めた変更の中から、
「これでOK！」
と思えたものを、最後に大元のブランチへ取り込むことができます。

この作業を
「マージ」
といいます。

ゲームの例でいうと、
・いろいろな育成ルートを試す
・いちばん良さそうな勇者を選ぶ
・その結果を本番データに反映する
というイメージです。

実際の開発でも、作業用ブランチで機能追加や修正を行い、問題がなければ大元のブランチに取り込んでいきます。

この流れがあるからこそ、
チーム開発でも安心して作業が進められるんです。

実際の現場ではどんな流れ？

ゲームの例でイメージできたところで、今回は実際の現場でよくある流れを見てみます。

だいたい、次のような流れになることが多いです。

最初は知らない言葉がいくつか出てきて、少し難しく感じるかもしれません。

でも、今回の段階ではまず
「大元から枝を作って、その中で安全に作業する」
というイメージが持てれば十分です。

実際にブランチを作ってみよう

ここまで、ブランチが
「大元のコードを残したまま、別ルートで安全に作業するための仕組み」
だというイメージが少しつかめてきたのではないでしょうか。

ではここからは、実際に手を動かして
ブランチを作る流れ
を試してみましょう！

今回は、練習用のフォルダを作って、その中でGitのブランチを作って行きます。
できるだけシンプルな流れにしているので、初心者の方でも試しやすいと思います。

事前準備

これから実際にGitの操作を試して行きますが、その前にひとつだけ確認しておきたいことがあります。

それは、自分のPCでGitが使える状態になっているかどうかです。

Gitは環境によって最初から使える場合もありますが、必ずしも最初から入っているとは限りません。

まずは、ターミナルで次のコマンドを入力してください

git --version

このコマンドでGitのバージョンが表示されれば、そのPCではGitコマンドが使える状態です

たとえば、次のように表示されればOKです。

git version 2.xx.x

Gitが入っていない場合は？

もし git –version を実行してもGitが使えない場合は、先にインストールしておきましょう。

Macの場合
初めてターミナルでgitを実行したときに、インストールを案内されることがあります。

Windowsの場合
Git for Windowsなどを使ってインストールするのが一般的です。

※詳しくは公式サイトを参照してください

ここまでできれば準備OK!

ここまで確認できたら、Gitを試す準備はOKです。
・ターミナルを開ける
・git –version でGitが使えると確認できる

この状態になっていれば、このあとのブランチ作成もスムーズに試しやすくなります。

練習用のフォルダを作る

まずは、練習用のフォルダを作ります。

mkdir git-branch-practice
cd git-branch-practice

ここでは、
・mkdir でフォルダを作る
・cd でそのフォルダの中に入る
という作業をしています。

つまり、
Gitの練習をするための場所を用意している
ということです。

Gitの管理を始める

次に、このフォルダをGitで管理できるようにします。

git init

これで、このフォルダの中でGitが使えるようになります。

git init は、
「ここからこのフォルダをGitで管理します」
と宣言するようなイメージです。

練習用のファイルを作る

次に、コミットするためのファイルを1つ作ります。

echo "はじめてのGitブランチ練習" > memo.txt

これで memo.txt というファイルが作られ、その中に文字が入ります。

今回はファイルの中身そのものよりも、
Gitで変更を記録するための対象を1つ作ること
が目的です。

ファイルの中身も確認してみる

ファイルを作れたら、実際に中身も確認してみましょう。

cat memo.txt

すると、次のように表示されます。

はじめてのGitブランチ練習

ここでは、memo.txt の中に
「はじめてのGitブランチ練習」
という文字が入っていることが確認できます。

cat は、
ファイルの中身をターミナル上に表示するコマンドです。

最初のコミットを作る

続いて、作ったファイルをGitに記録します。

git add memo.txt
git commit -m "最初のコミット"

ここでやっていることは次の通りです。

• git add memo.txt
  →このファイルをコミット対象に入れる
• git commit -m “最初のコミット”
  →実際に変更を記録する

これで、
大元になる最初のセーブポイント
ができました。

今いるブランチを確認する

今、自分がどのブランチにいるのか確認してみましょう。

git branch

すると、以下のように表示されます。

この＊がついているのが、
今自分がいるブランチです。

新しいブランチを作る

では、作業用ブランチを作ってみます。

git branch feature-1

これで、feature-1 という新しいブランチが作られました。

ただし、ここでひとつ注意です。

このコマンドは
ブランチを作るだけで
まだそのブランチには移動していません。

もう一度、自分の今いるブランチを確認してみましょう。

git branch

すると、以下のような表示になります。

この状態では、feature-1 は作られていますが、
まだ自分は master にいることがわかります。

作ったブランチに移動する

次は、作成したブランチに移動します。

git switch feature-1

もう一度、自分の今いるブランチを確認してみましょう。

git branch

すると、以下の様な表示になります。

これで、
feature-1 ブランチに移動できたことがわかります。

ブランチの中で変更してみる

では、新しく作ったブランチの中でファイルを変更してみましょう。

echo "feature-1で文章を追記しました" >> memo.txt

この >> は、もともとの内容の下に追記する書き方です。

続いて、この変更をコミットします。

git add memo.txt
git commit -m "feature-1で追記"

これで、feature-1 ブランチの中で新しい変更が記録されました。

追記したあと、中身をもう一度確認してみる

では、ブランチの中で文章を追記したあと、もう一度 memo.txt の中身を見てみましょう。

cat memo.txt

すると、次のように表示されます。

はじめてのGitブランチ練習
feature-1で文章を追記しました

このように、最初の文章の下に新しい文章が追加されているのがわかります。

つまりここでは、
「ブランチの中でファイルを変更し、その変更をコミットした」
ということになります。

コミットの流れを見てみる

今までの流れを見やすく表示してみます。

git log --oneline --graph --all

このコマンドを使うと、
コミットの流れや枝分かれの様子を確認しやすくなります。

最初は表示の見方が少し難しく感じるかもしれませんが、
「Gitではこうやって流れが分かれて管理されているんだな」
と感じられればOKです。

作成と移動を同時にやる方法もある

実際には、ブランチ作成と移動をまとめて行うことも多いです。

その場合は、次のコマンドを使います。

git switch -c feature-2

これは、
・feature-2 というブランチを作る
・そのまま feature-2 に移動する
という2つを同時にやってくれる便利な書き方です。

ここで理解できればOKなこと

ここまで試してみて、特に大事なのは次の3つです。

• Gitではブランチを作ることができる
• ブランチは作っただけでは移動しない
• 移動した先のブランチでコミットすると、その枝の中で作業が進んでいく

この感覚が掴めると、
「ブランチってこういうことか！」
とかなり理解しやすくなります。

まとめ

どうでしたか？

今回は、
Gitのブランチとは何か
について、やさしく解説してみました。

ブランチを使うことで、

• 大元のコードを壊さずに作業できる
• 別パターンを安心して試せる
• チーム開発がしやすくなる

という大きなメリットがあります。

最初は少し難しく感じるかもしれませんが、
実際に手を動かしてみると、少しずつイメージがつかめてきます。

まずはぜひ、自分のPCでブランチを作ってみてください。
自分で少しずつ理解してくると、Gitがぐっとおもしろくなってきますよ！

今回は、「ブランチって何？」という部分にしぼって解説してきました。

ですが、実際のGitの操作ではブランチを作って編集したあと
ステージングする→コミットする→大元のブランチへ反映していく
という流れがとても大切になります。

次回は、このあたりの流れを初心者向けにやさしく解説していきます！

今日の学びが、誰かの役に立てたらうれしいです！