Gitブランチとは？初心者向けに基本から使い方まで徹底解説

プログラミングを学び始めると、必ず出てくる「Git」と「ブランチ」という言葉。

「ブランチって何？」「なぜ必要なの？」「どうやって使うの？」

この記事では、Gitのブランチについて、プログラミング初心者の方にもわかりやすく、基本から実際の使い方まで徹底解説します。

そもそもGitとは？
1. バージョン管理システム
2. GitとGitHubの違い
ブランチとは？
なぜブランチが必要なの？
ブランチの基本概念
ブランチの基本操作
実践：ブランチを使った作業フロー
コンフリクト（競合）とは？
1. コンフリクトが起こる状況
2. コンフリクトの解決方法
よくある質問
ブランチ戦略（チーム開発）
1. Git Flow
2. GitHub Flow
便利なGitコマンド集
1. ブランチ関連
2. 履歴確認
まとめ：ブランチを使いこなそう

そもそもGitとは？

バージョン管理システム

Git（ギット）は、バージョン管理システムです。

簡単に言うと、ファイルの変更履歴を記録して管理するツールのこと。

例えば：

レポートを書いているとき
レポート_最終版.docx
レポート_最終版2.docx
レポート最終版本当に最終.docx

こんな経験、ありませんか？

Gitを使えば、このような管理をスマートに行えます。

GitとGitHubの違い

よく混同されますが、GitとGitHubは違います。

Git：バージョン管理システム（ツール）
GitHub：Gitを使ったプロジェクトを保存・共有するサービス（ウェブサイト）

ブランチとは？

木の枝のように分岐させる機能

ブランチ（branch）は、英語で「枝」「支流」「分岐」という意味です。

Gitにおけるブランチとは、プロジェクトの開発の流れを枝分かれさせる機能のことです。

たとえ話：本を書く場合

わかりやすく例えると：

状況：あなたは小説を書いています。

問題：

現在のストーリー（メインストーリー）を進めたい
同時に、別エンディングも試してみたい
でも、メインストーリーを壊したくない

解決策：ブランチを使う

メインブランチ：正式なストーリー
別エンディングブランチ：実験的な別ストーリー

この2つの「世界線」を同時に進められるのがブランチです。

気に入った別エンディングは、後でメインストーリーに統合（マージ）できます。

プログラミングでの実際の使い方

例：ウェブサイト開発

メインブランチ（main）：

実際に公開されている安定版

機能追加ブランチ（feature/new-login）：

新しいログイン機能を開発中
まだテスト段階

バグ修正ブランチ（fix/button-bug）：

ボタンのバグを修正中

このように、複数の作業を同時並行で進められます。

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

メリット1：本番環境を壊さない

メインのコード（本番環境）に影響を与えずに、新機能を開発できます。

ブランチなし：

新機能を追加 → バグが発生 → 本番環境が動かない！

ブランチあり：

別ブランチで新機能を開発 → テスト → 問題なければ統合
本番環境は常に安定

メリット2：複数人で同時に作業できる

チーム開発では、複数のメンバーが同時に異なる機能を開発します。

Aさん：ログイン機能を開発（branchA）
Bさん：検索機能を開発（branchB）
Cさん：デザイン変更（branchC）

お互いに影響を受けずに作業できます。

メリット3：履歴が整理される

作業ごとにブランチを分けることで、何をいつ変更したか明確になります。

問題発生時：

どのブランチ（どの機能追加）で問題が起きたかすぐわかる
その部分だけ元に戻せる

メリット4：実験しやすい

新しいアイデアを気軽に試せます。

失敗しても大丈夫：

実験用ブランチで試す
うまくいかなければそのブランチを削除
メインブランチには影響なし

ブランチの基本概念

メインブランチ（main / master）

プロジェクトの中心となるブランチです。

特徴：

安定したバージョンを保持
リリース（公開）用のコード
以前は「master」、最近は「main」が主流

注意：
メインブランチには、テスト済みの安定したコードのみを統合します。

作業ブランチ（トピックブランチ）

メインブランチから分岐した、作業用のブランチです。

命名例：

feature/login（機能追加：ログイン）
fix/button-color（バグ修正：ボタンの色）
update/readme（更新：READMEファイル）

ポイント：
ブランチ名は、作業内容がわかるように付けます。

HEAD

HEADとは、今どのブランチで作業しているかを示すポインタです。

イメージ：
「あなたは今、どの世界線にいるか」を示す目印

ブランチの基本操作

前提：Gitのインストール

以下のコマンドは、Git がインストールされている前提で説明します。

インストール確認：

git --version

バージョンが表示されればOKです。

1. ブランチを確認する

現在のブランチを確認：

git branch

表示例：

* main
  feature/login
  fix/button

*マークが付いているのが、現在作業中のブランチです。

すべてのブランチを確認（リモート含む）：

git branch -a

2. ブランチを作成する

新しいブランチを作成：

git branch ブランチ名

例：

git branch feature/new-header

注意：
このコマンドは作成のみで、ブランチの切り替えは行いません。

3. ブランチを切り替える

ブランチを切り替え：

git checkout ブランチ名

または（新しいコマンド）

git switch ブランチ名

例：

git checkout feature/new-header

または

git switch feature/new-header

4. ブランチを作成して同時に切り替える

便利なコマンド：

git checkout -b ブランチ名

または

git switch -c ブランチ名

例：

git checkout -b feature/contact-form

これで、feature/contact-formブランチを作成して、そのブランチに切り替わります。

5. ブランチをマージ（統合）する

作業が完了したブランチを、メインブランチに統合します。

手順：

ステップ1：メインブランチに切り替える

git checkout main

ステップ2：作業ブランチをマージ

git merge ブランチ名

例：

git checkout main
git merge feature/new-header

これで、feature/new-headerの変更がmainに統合されます。

6. ブランチを削除する

不要になったブランチを削除します。

ローカルブランチを削除：

git branch -d ブランチ名

例：

git branch -d feature/new-header

注意：
マージ済みのブランチのみ削除できます。

強制削除（マージしていなくても削除）：

git branch -D ブランチ名

実践：ブランチを使った作業フロー

実際の開発の流れを見てみましょう。

ステップ1：プロジェクトの準備

# 新しいディレクトリを作成
mkdir my-project
cd my-project

# Gitリポジトリを初期化
git init

# 最初のファイルを作成
echo "# My Project" > README.md

# ファイルをステージング
git add README.md

# 最初のコミット
git commit -m "Initial commit"

ステップ2：新機能開発用のブランチを作成

# 新機能用のブランチを作成して切り替え
git checkout -b feature/add-about-page

# 現在のブランチを確認
git branch

表示：

* feature/add-about-page
  main

ステップ3：新機能を開発

# 新しいファイルを作成
echo "About Us" > about.html

# 変更をステージング
git add about.html

# コミット
git commit -m "Add about page"

ステップ4：メインブランチに統合

# メインブランチに切り替え
git checkout main

# 作業ブランチをマージ
git merge feature/add-about-page

# 不要になったブランチを削除
git branch -d feature/add-about-page

ステップ5：確認

# ブランチ一覧を確認
git branch

# コミット履歴を確認
git log --oneline

コンフリクト（競合）とは？

コンフリクトが起こる状況

複数のブランチで、同じファイルの同じ箇所を編集すると、マージ時にコンフリクトが発生します。

例：

mainブランチ：

<h1>Welcome</h1>

branchA：

<h1>Welcome to Our Site</h1>

branchB：

<h1>Hello World</h1>

branchAとbranchBを両方mainにマージしようとすると、Gitは「どっちを採用すればいいの？」と困ります。

コンフリクトの解決方法

ステップ1：コンフリクトを確認

マージ時にエラーメッセージが表示されます：

CONFLICT (content): Merge conflict in index.html
Automatic merge failed; fix conflicts and then commit the result.

ステップ2：ファイルを開いて確認

コンフリクトが発生したファイルを開くと、以下のように表示されます：

<<<<<<< HEAD
<h1>Welcome to Our Site</h1>
=======
<h1>Hello World</h1>
>>>>>>> branchB

説明：

<<<<<<< HEAD：現在のブランチ（main）の内容
=======：区切り線
>>>>>>> branchB：マージしようとしているブランチの内容

ステップ3：手動で修正

どちらを採用するか、または両方を組み合わせるかを決めます。

例：

<h1>Welcome to Our Site - Hello World</h1>

記号（<<<<<<<など）はすべて削除します。

ステップ4：変更をコミット

git add index.html
git commit -m "Resolve merge conflict"

よくある質問

Q1：ブランチとコミットの違いは？

A：

コミット：変更の記録（スナップショット）
ブランチ：コミットの流れ（系統）

ブランチは、コミットの集まりを指します。

Q2：mainとmasterの違いは？

A：

同じものです。

master：昔のデフォルト名
main：2020年以降のデフォルト名

GitHubなどが差別的な用語を避けるため、「main」に変更しました。

Q3：ブランチをたくさん作っても大丈夫？

A：

大丈夫です！

Gitのブランチは非常に軽量なので、気軽に作成できます。

推奨：

小さな機能追加ごとにブランチを作る
不要になったらすぐ削除

Q4：ブランチ名の付け方のルールは？

A：

明確なルールはありませんが、一般的な命名規則：

プレフィックス（接頭辞）を使う：

feature/：新機能
fix/：バグ修正
hotfix/：緊急修正
update/：更新
refactor/：リファクタリング

例：

feature/user-login
fix/navbar-bug
update/readme-instructions

Q5：リモートブランチとは？

A：

GitHubなどのリモートリポジトリにあるブランチです。

ローカルブランチ：自分のパソコン上
リモートブランチ：GitHubなどのサーバー上

リモートブランチの取得：

git fetch
git checkout origin/feature/new-feature

Q6：プルリクエスト（PR）とは？

A：

プルリクエスト（Pull Request）は、GitHubなどで使われる機能で、「このブランチの変更をメインブランチに統合してください」というお願いです。

流れ：

自分のブランチで作業
GitHubにプッシュ
プルリクエストを作成
レビュー担当者が確認
承認されたらマージ

ブランチ戦略（チーム開発）

Git Flow

大規模プロジェクトでよく使われる戦略です。

ブランチの種類：

main（master）：本番環境
develop：開発の中心
feature：機能開発
release：リリース準備
hotfix：緊急修正

GitHub Flow

よりシンプルな戦略です。