Git 入門（後編）：ブランチ運用と変更の取り消し

ブランチは Git の最強機能。これをマスターすれば、安全に新機能を開発できます。

---

はじめに

この記事のゴール

• ブランチの概念を理解し、作成・切り替えができる
• git reset の 3 つのモードを使い分けられる
• git stash で作業を一時保存できる

シリーズ構成

この Git/GitHub 入門は 3 部構成です：

1. Git 入門（前編）：バージョン管理の基礎と初期設定
2. Git 入門（後編）：ブランチ運用と変更の取り消し ← 今ここ
3. GitHub 入門：リモート連携とチーム開発

---

0. ブランチとはなんだ？

ブランチとは、まさに Git の起こした革命の一つです。

例えば、あなたは現在、新たな動画配信アプリを開発しています。そのアプリには、視聴者が配信者に「スタンプ」を送れる機能を追加したいとします。

しかし、スタンプ機能の開発中にバグが混ざってしまったらどうでしょうか？
もし、すべての作業を一つの線（main ブランチ）上でやっていたら、未完成でバグだらけのコードが、今すぐ本番に混ざってしまう危険があります。

そこで登場するのが ブランチ（branch） です。

ブランチとは：

「今動いているアプリ（幹）から、一時的に枝を生やして、そこで自由に実験・開発できる仕組み」

のことです。

イメージとしては、次のような感じです。

(main)───●────●────●────────→  本番で動いている安定したコード
              \
               └───(stamp-feature ブランチ)──●──●──→  スタンプ機能を開発するための枝

• main：ユーザーに届ける、安定したアプリのコード
• stamp-feature：スタンプ機能だけを好きにいじるための「開発用の枝」

このようにブランチを使うことで、

• 新機能を「別ルート」で安全に開発できる
• うまくいったら main にマージ（統合）すればよい
• 失敗したらブランチごと消せば、main には一切影響しない

という開発スタイルが可能になります。

これが、Git における「ブランチ」の基本的な考え方です。

1. ブランチ運用の基礎

master/main とは

master（または main）は、木の「幹」のようなものです。実際にユーザーに届く（リリース・デリバリー）ソースコードが含まれる、メインのブランチです。

Tips：ソースコードとは？ ソースコードとは、コンピュータに動作を指示するための「人間が書く文章」です。 ただしコンピュータは、この文字のまま読んでいるわけではありません。

print("I love Git!")

人間が書いたコードをもとに、最終的には 0101 … のような二進数（機械語）へ翻訳（コンパイル）されたものをコンピュータは実行します。 この “源（source）のコード” だから ソースコード（source code） と呼ばれます。

---

現在のブランチを確認

git branch

feature ブランチを作る

安定したコードベース（mainブランチのこと）があり、バグ修正や新機能を試したい場合は、新しいブランチを作成します。

# 新しいブランチを作成して切り替え
git checkout -b feature/user-auth

# または（Git 2.23以降）
git switch -c feature/user-auth

これで、このブランチで書いたコードは master に影響を与えません。

ブランチを切り替える

git checkout master

# または
git switch master

切り替えると、feature ブランチで追加したファイルは消え、元の master の状態に戻ります。

---

2. 変更を巻き戻す方法

git reset の3つのモード

モード	効果
--soft	コミットだけ取り消し、変更はステージングに残る
--mixed（デフォルト）	コミットを取り消し、変更は作業ディレクトリに残る
--hard	コミットも変更も完全に削除

# 直前のコミットを取り消し（変更は保持）
git reset --soft HEAD~1

# 直前のコミットを取り消し（変更はステージング解除）
git reset HEAD~1

# 直前のコミットと変更を完全に削除（危険！）
git reset --hard HEAD~1

初心者がやりがちなミスと危険ポイント

1. --hard の誤用: 取り消し不可能なので、本当に必要なときだけ使う
2. push 済みのコミットを reset: 他の人の履歴を壊す可能性がある
3. 何を reset しているか理解していない: 必ず git log で確認してから

---

3. WIP を保存する git stash

WIP（Work In Progress）とは？

WIP は、未完成の作業（作業途中の変更）を示すラベルのことで、
git stash が自動的に付けるメッセージとしても使われます。

前回の記事で、次のように説明しました：

プロジェクト内でファイルを作成・変更しても、Git にはそれが記録されていません。宙ぶらりんの状態です。それを確定するために、変更を Git に保存（コミット）する必要があります。

ただし、コミットしていなくてもブランチを切り替えたり、別の作業に移ったりすることは"技術的には" 可能です。
とはいえ、そのまま切り替えると作業内容が衝突したり、上書きされたりする危険があります。

そこで安全に一時退避するために使うのが git stash です。

いつ使うべきか？

作業が途中で、まだコミットしたくない。でもブランチを切り替えたい。そんなときに使います。

# 現在の変更を一時保存
git stash

# 保存した変更を復元
git stash pop

# 保存した変更を復元（stash は残す）
git stash apply

# stash の一覧を表示
git stash list

commit と stash の使い分け

状況	推奨
機能が完成した	commit
作業途中だが記録に残したい	commit（WIP: などのプレフィックス付き）
一時的に別ブランチで作業したい	stash
実験的なコードを後で試したい	stash

---

4. マージの基礎

git merge

feature ブランチの作業が完了したら、master にマージします。

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

# feature ブランチをマージ
git merge feature/user-auth

fast-forward / no-ff の違い

# Fast-forward（履歴が一直線）
git merge feature/user-auth

# No fast-forward（マージコミットを作成）
git merge --no-ff feature/user-auth

no-ff を使うと、「ここで機能がマージされた」という記録が残り、履歴が追いやすくなります。

squash merge の意味とメリット

git merge --squash feature/user-auth
git commit -m "✨ ユーザー認証機能を追加"

feature ブランチで作った複数のコミット（「絵文字追加」「typo 修正」など）を 1つのコミットにまとめて マージします。

メリット:

• master の履歴がスッキリする
• feature ブランチの細かいコミットは保持される

---

5. マージコンフリクト

なぜ起こる？

同じファイルの同じ行を、複数のブランチで変更した場合に発生します。Git は「どちらの変更を使うべきか」判断できません。

VS Code での解決手順

コンフリクトが発生すると、VS Code が以下のような表示をします：

<<<<<<< HEAD
const greeting = "Hello";
=======
const greeting = "Hi";
>>>>>>> feature/new-greeting

VS Code では以下のオプションが表示されます：

1. Accept Current Change: HEAD（現在のブランチ）の変更を採用
2. Accept Incoming Change: マージするブランチの変更を採用
3. Accept Both Changes: 両方の変更を保持
4. Compare Changes: 差分を比較

💡 Pro Tip: abort してから手動で直す

# マージを中止
git merge --abort

コンフリクトが複雑な場合は、一度 abort して、ファイルを手動で整理してから再度マージするのが安全です。

---

6. よくあるミスと対処法

コミットを取り消したい

# 直前のコミットを取り消し（変更は保持）
git reset --soft HEAD~1

# コミットメッセージを修正
git commit --amend -m "新しいメッセージ"

ファイルを間違って追加した

# ステージングから除外（ファイルは削除されない）
git reset HEAD ファイル名

# 既にコミット済みの場合
git rm --cached ファイル名
git commit -m "🔥 不要なファイルを削除"

.gitignore が効かない

すでに追跡されているファイルは .gitignore に追加しても無視されません。

# キャッシュをクリア
git rm -r --cached .
git add .
git commit -m "🔧 .gitignore を適用"

コンフリクト地獄になった時の対処順序

1. 落ち着く（まずは深呼吸）
2. git status で状況を確認
3. 簡単なファイルから解決
4. 複雑すぎる場合は git merge --abort で一度リセット
5. 小さい単位で再度マージ
6. 分からなければチームメンバーに相談

---

まとめ

この記事では、Git のブランチ運用と変更の取り消しについて学びました：

• ✅ git branch / git checkout -b でブランチを操作
• ✅ git reset の 3 つのモード（soft / mixed / hard）
• ✅ git stash で作業を一時保存
• ✅ git merge でブランチを統合
• ✅ コンフリクトの解決方法

次のステップ

次の記事「GitHub 入門：リモート連携とチーム開発」では、以下を学びます：

• GitHub へのプッシュ
• Pull Request の作り方
• チーム開発のワークフロー

---

コマンドチートシート（後編）

# ブランチ
git branch                        # ブランチ一覧
git checkout -b <name>            # 新規ブランチ作成＆切り替え
git checkout <name>               # ブランチ切り替え
git switch -c <name>              # 新規ブランチ作成＆切り替え（新構文）
git switch <name>                 # ブランチ切り替え（新構文）

# マージ
git merge <name>                  # ブランチをマージ
git merge --no-ff <name>          # マージコミットを作成
git merge --squash <name>         # コミットをまとめてマージ
git merge --abort                 # マージを中止

# 取り消し
git reset --soft HEAD~1           # コミット取り消し（ステージング保持）
git reset HEAD~1                  # コミット取り消し（変更は保持）
git reset --hard HEAD~1           # 完全に削除（危険！）
git commit --amend -m "message"   # 直前のコミットメッセージ修正

# 一時保存
git stash                         # 変更を一時保存
git stash pop                     # 一時保存を復元
git stash list                    # stash 一覧

---

前の記事：Git 入門（前編）：バージョン管理の基礎と初期設定

次の記事：GitHub 入門：リモート連携とチーム開発