🧩 1. はじめに：Gitがもたらす「並列開発の自由」
モダンな開発現場では、以下のような要件が求められます：
- 複数人が同時に別々の機能を開発したい
- バグ修正をすぐにリリースしたい
- 安定したコードベース（main/master）を常に保ちたい
これを支えるのが、Git の ブランチ戦略とマージ戦略です。
しかし実際の現場では…
😱「ブランチの運用ルールが曖昧で、どこで作っていいかわからない」
😱「マージしたら突然のコンフリクト。あれ、俺の変更どこいった？」
😱「rebase？それって壊れるやつでしょ？」
こうした誤解や不安は、Git のメンタルモデルをしっかり理解することで解消できます！
🔍 2. ブランチとは何か？〜Gitの基本構造を視覚で理解する〜
📌 Git の内部構造をざっくり理解しよう
Git では、以下の3つがすべてです：
- コミット（commit）：ある時点のスナップショット
- ブランチ（branch）：最新のコミットを指すポインタ
- HEAD：現在の作業位置を指すポインタ
(main)----A----B----C ← main ブランチ（HEADがここを指す）
↑
pointer（main）
新しいブランチを作るとは、「今の HEAD がいる場所から、新しいポインタを作る」だけ！
🛠️ ブランチ基本コマンドまとめ
| 操作 | コマンド | 説明 |
|---|---|---|
| ブランチ一覧表示 | git branch |
現在のブランチ一覧を見る |
| ブランチ作成 | git branch <名前> |
現在の位置から分岐を作る |
| 作成＆切り替え（推奨） | git checkout -b <名前> |
作ってすぐ移動 |
| 削除 | git branch -d <名前> |
マージ済みブランチの削除 |
| 強制削除 | git branch -D <名前> |
マージしてないけど削除 |
💻 3. 実践！git branch & merge を使った開発シナリオ
🧪 実験用レポジトリを初期化
mkdir git-branch-demo && cd git-branch-demo
git init
echo "v1" > version.txt
git add .
git commit -m "Initial commit: v1"
🛤️ ブランチを分けて機能追加
git checkout -b feature/upgrade-version
echo "v2" >> version.txt
git commit -am "Add v2 version info"
現在の状態：
main: A---B
\
feature: C (v2追加)
🔗 マージして main に統合
git checkout main
git merge feature/upgrade-version
マージ後：
main: A---B-------D (マージコミット)
\ /
C
⚠️ 4. コンフリクトを制する者は Git を制す！
🧨 コンフリクトの再現例
# 別のブランチを作って同じ行を編集
git checkout -b feature/conflict-test
echo "conflict line" > conflict.txt
git add . && git commit -m "Add conflict line on feature branch"
git checkout main
echo "base line" > conflict.txt
git add . && git commit -m "Add base line on main branch"
# マージすると…
git merge feature/conflict-test
結果：
Auto-merging conflict.txt
CONFLICT (content): Merge conflict in conflict.txt
Automatic merge failed; fix conflicts and then commit the result.
ファイルを開くと：
<<<<<<< HEAD
base line
=======
conflict line
>>>>>>> feature/conflict-test
これを適切に修正し、git add して git commit すればOK。
🔧 5. 実務ノウハウ：Gitブランチ運用術（GitHub Flow）
GitHub や GitLab では、以下のようなブランチ戦略が実践されています。
🔄 GitHub Flow の基本ルール
- main は常にデプロイ可能な状態
- 機能ごとにブランチを作成（
feature/xxx） - Pull Request（PR）を送ってレビュー＆CI
- 問題なければマージ（Squash推奨）
📋 PR マージ方法の違い
| マージ方法 | 特徴 |
|---|---|
| Merge Commit | 履歴が残るが、複雑になりがち |
| Squash & Merge | 履歴が1つにまとまる。CI通知もスッキリ |
| Rebase & Merge | 直線的な履歴。上級者向けで衝突に注意 |
🚧 6. よくあるミス & 解決策まとめ
| ミス例 | 対応策 |
|---|---|
main に直接コミットしてしまう |
main への保護ブランチ設定 |
| 不要なブランチが放置される | 定期的に git branch -d で整理 |
rebase で履歴が壊れる |
公開済みのブランチでは避ける |
🧠 7. 応用知識：git cherry-pick, revert, stash の使いどころ
🍒 git cherry-pick
特定のコミットだけ他のブランチに適用したいときに使います。
git cherry-pick <commit-hash>
🔙 git revert
本番に入ってしまった「やばいコミット」を打ち消す方法
git revert <commit-hash>
→ 安全に取り消せる
🎒 git stash
作業途中だけど一旦切り替えたいときに
git stash # 一時退避
git stash pop # 復元
🧭 8. Git GUIやGitHub Desktopも活用しよう！
Git コマンドに慣れることは大事ですが、GUIツールの併用も効率化の鍵です。
おすすめ：
- GitHub Desktop（初心者に最適）
- Fork
- Sourcetree
- VSCode Git Extension
🎯 9. まとめ：Git を味方にして、チーム開発の武器にしよう！
💡 本記事のまとめ
-
git branchは安全に並行開発を可能にする基本機能 -
git mergeはコード統合の要。コンフリクトへの理解が重要 - GitHub Flow などの戦略と併用することで、開発効率と品質がUP
- GUIとCLIを併用して、ストレスフリーなGit運用を目指そう！
📘 次に学びたいこと
- CI/CD における Git の役割
-
git rebaseの徹底理解（図解付き） - GitHub Actions による自動化
💬 おわりに
Git は最初こそ難しく感じるかもしれませんが、構造と目的がわかれば強力な開発の武器になります。
ぜひこの記事のコマンドをローカルで試して、自分の手で「動かして理解する」ことをおすすめします！
✨ Qiita での「LGTM」やコメントも大歓迎です！
次回の記事：「コンフリクトの解決方法」もぜひお楽しみに！