はじめに
物語を書いているとします。筋書きが「主人公がドラゴンと戦う」と「主人公がドラゴンと友達になる」の 2 通りに分かれる場面に来ました。どちらがよいか確かめるために両方の展開を書きたいものの、元の原稿を台無しにはしたくありません。
Git のブランチを使うと、まさにこのような作業ができます。ブランチは、安心して試行錯誤できる並行した開発ラインを作成します。分離した作業を簡単かつ低コストで行えるため、ブランチは Git の最も重要な考え方の 1 つです。
Git のブランチは、プロジェクト全体の完全なコピーではありません。主に、コミットの流れを指す移動可能なポインターです。そのため、ブランチは高速かつ軽量に作成できます。
- 機能を開発する：新しいログインシステムを別の作業領域で構築します。
- 試行錯誤する：現在の Web サイトを壊さずに、新しいデザイン案を試します。
- バグを修正する：重大なエラーを分離した状態で修正します。
この実験では、並行した開発ライン（ブランチ）を作成し、その中で変更を加えた後、メインの開発ラインに戻ります。これにより、試した変更が元のプロジェクトに影響していないことを確認します。
機能ブランチを作成する
Git リポジトリは、デフォルトで 1 つのメインブランチから始まります。通常は master または main という名前です。これは、プロジェクトの公式で安定したバージョンである「基準となる開発ライン」と考えてください。
メインプロジェクトの安定性を損なうことなく、新機能（ログインページなど）を開発するには、新しいブランチを作成します。
現在のブランチを確認します。
git branch
出力：
* master
* は、現在 master ブランチにいることを示します。
このマークは、現在のブランチコンテキストを示します。Git の多くのコマンドは、HEAD が現在指しているブランチを基準に動作するため、自分がどのブランチにいるかを把握しておくことが重要です。
feature_login という名前の新しいブランチを作成します。
git branch feature_login
これで新しい開発ラインが作成されました。ただし、まだそのブランチに切り替わってはいません。
ここで、Git における重要な違いが分かります。ブランチの作成と、ブランチへの切り替えは別の操作です。ブランチは存在していても、現在の作業コンテキストになっているとは限りません。
ブランチが作成されたことを確認します。
git branch
出力：
feature_login
* master
feature_login ブランチは存在しますが、* は現在も master にいることを示しています。
新しいブランチに切り替える
開発ラインを作成するだけでは不十分です。そのブランチに移動する必要があります。ブランチを切り替えるコマンドは git checkout です。
新しいブランチに切り替えます。
git checkout feature_login
出力：
Switched to branch 'feature_login'
切り替わったことを確認します。
git branch
出力：
* feature_login
master
アスタリスク（*）が移動しました。これで feature_login ブランチ内で作業しています。ここから加える変更は、すべてこのブランチに対して行われます。
より正確には、ここで作成する新しいコミットは master ではなく feature_login を進めます。ただし、2 つのブランチは分岐した地点までの過去の履歴を共有しています。
機能ブランチで作業する
安全な実験用の作業領域に移動できたので、コードを書いてみましょう。ここでは「ログイン機能」のスクリプトを作成します。
login.sh という名前のファイルを作成します。
echo "echo 'Logging in...'" > login.sh
フォルダー内にファイルが存在することを確認します。
ls
master から引き継いだ README.md と、新しく作成した login.sh の両方が表示されます。
この時点で、login.sh はディスク上にあるだけのファイルです。このファイルをこのブランチの履歴に正式に保存するには、コミットする必要があります。
これはブランチの考え方を理解するうえで重要です。ファイルは作業ツリーに現れますが、そのブランチの履歴が変わるのは、そのブランチでコミットを作成したときだけです。
ブランチに変更をコミットする
作業内容を保存しましょう。Git の標準的なワークフローは、Initialize -> Stage -> Commit です。
ステータスを確認します。
git status
login.sh は Untracked と表示されます。
ファイルをステージングします。
git add login.sh
feature_login の履歴にファイルをコミットします。
git commit -m "Add login feature script"
出力：
[feature_login 8a2b3c] Add login feature script
これで変更が永続的に記録されました。ただし、記録されたのは**feature_login の開発ラインだけ**です。
この分離状態が、ブランチが便利な理由です。準備が整うまでメインブランチを進めずに、開発、テスト、試行錯誤を行えます。
ブランチの分離を確認する
ここが重要な確認ポイントです。feature_login は master とは別の領域だと説明しました。master に戻って、それを確認しましょう。
master ブランチに戻ります。
git checkout master
出力：
Switched to branch 'master'
ファイルを確認します。
ls
login.sh はどこにありますか。消えています。
これが意図した動作です。master の開発ラインには、login.sh が存在しません。試した変更は安全に分離されています。
ファイルが永久に失われたわけではないことを確認するため、機能ブランチに戻ります。
git checkout feature_login
ls
login.sh が再び表示されます。開発ラインを切り替えると、Git はディレクトリ内のファイルをすぐに入れ替えます。
まとめ
この実験では、ブランチの力を学びました。
- 安全性：メインのコード（
master）に影響を与えず、別のブランチ（feature_login）で新機能を構築できます。 - コンテキストの切り替え：
git checkoutを使って、並行した開発ライン間を移動しました。 - 分離：一方のブランチでコミットした変更が、別のブランチには現れないことを確認しました。
プロフェッショナルなチームは、このように作業します。開発者は新機能やバグ修正ごとにブランチを作成し、メインのコードベースをクリーンで安定した状態に保ちます。
