【完全ガイド】git: Your local changes would be overwritten by merge の原因と解決方法｜stash/commit/checkout まで徹底解説

Git で日常的に遭遇する頻出エラー:

$ git pull origin main
error: Your local changes to the following files would be overwritten by merge:
        src/config.js
        README.md
Please commit your changes or stash them before you merge.
Aborting

作業を進めようとした瞬間、突然出るこのエラー。「commit するか stash しろ」とは書いてあるけど、どっちを選べばいいのか、どっちが正解なのか分からない…。

現場では:

• stash と commit、どっちが正しい？
• どの解決策が最も安全？
• rebase を使う手もあるらしいけど
• git reset --hard は危険と聞いたけど
• Stable Diffusion Web UI 更新でハマった
• CI/CD で頻発する
• 予防する方法はある？

など、選択肢が多くて迷います。間違った選択で大切な変更を失うリスクもあります。

しかも、選択肢が5つ以上あり、それぞれに向いた場面が違うため、正しい判断ができないと同じミスを繰り返すことに。

本記事では、Your local changes would be overwritten by merge の完全な原因と5つの解決方法を、リファレンスとして実用的に整理します。エラーの本質、発生パターン、git stash、git commit、git restore / git checkout、git pull --rebase --autostash、git reset --hard の使い分け、判断フロー、実践シナリオ、予防のベストプラクティス、FAQまで完全網羅。この1本で選択に迷わず、最適な対処ができるようになります。

結論：状況別の最速解決

時間がない方向けに、最適な選択を先に示します。

判断フロー

質問1: ローカルの変更を残したい？
       ├─ Yes → 質問2
       └─ No  → git checkout . && git pull（破棄）

質問2: すぐ commit したい？
       ├─ Yes → commit → pull
       └─ No  → stash → pull → stash pop

最も便利な一発解決

# stash + pull + pop を自動化（rebase 版）
git pull --rebase --autostash

# または push もするなら
git pull --rebase --autostash origin main

未commit の変更を維持したまま pull できる万能コマンド。

状況別 早見表

詳細は以下で解説します。

まず理解する：エラーの本質

メッセージの意味

error: Your local changes to the following files would be overwritten by merge:
        src/config.js
Please commit your changes or stash them before you merge.

翻訳:「あなたのローカルの変更が、merge によって上書きされてしまいます。commit または stash してください」

つまり:

1. あなたのローカルには未commit の変更がある
2. git pull （= fetch + merge）で同じファイルを引っ張ってこようとしている
3. Git は「あなたの変更を消してもいい？」と確認できないため、merge を中止して保護

なぜ発生するか

[リモート]                    [あなたのローカル]
main: A ─ B ─ C ─ D          main: A ─ B ─ C
                                          + 未commitの変更（src/config.js）

git pull で D を取り込もうとするが、D が src/config.js を変更していると、あなたの未commit変更が上書きされる。

Git はこれを察知して、安全のため merge を拒否。

どの操作で発生するか

• git pull（fetch + merge）
• git merge <branch>
• git checkout <branch> / git switch <branch>
• git rebase

「ブランチを移動する系」の操作でよく発生します。

似ているが違うエラー

詳細はgit merge conflict の記事、unrelated histories の記事、git push rejected の記事も参照。

解決策①：git stash（推奨）

未commit の変更を残したい・すぐcommit したくない場合の第一選択。

手順

# 1. 変更を退避
git stash push -u -m "before pull"
# -u: untracked も含める

# 2. pull
git pull origin main

# 3. 変更を戻す
git stash pop

conflict on pop の対応

git stash pop
# CONFLICT (content): Merge conflict in src/config.js

→ 通常の conflict と同じ:

vim src/config.js
git add src/config.js
# stash は pop 時 conflict では自動削除されないので手動
git stash drop

詳細はgit stash 使い方の記事、git merge conflict の記事も参照。

メリット

• 変更を確実に残せる
• 失敗しても stash apply で復旧可能（pop なら削除、apply なら残す）
• 中身を後で確認できる

デメリット

• 3ステップかかる
• pop 時に conflict の可能性

解決策②：git pull –rebase –autostash（プロ向け一発解決）

stash の3ステップを1コマンドで自動化する最強コマンド:

git pull --rebase --autostash

動作

1. stash（自動） で未commit 変更を退避
2. rebase 方式 でリモートを取り込み
3. stash pop（自動） で変更を戻す

恒久設定

~/.gitconfig:

git config --global pull.rebase true
git config --global rebase.autoStash true

これで git pull だけで自動的に上記の動作。

Git 中〜上級者の標準的な設定。

メリット

• 1コマンドで解決
• 履歴が線形（merge commit なし）
• stash 操作を意識不要

デメリット

• rebase の性質を理解している必要
• conflict 発生時は rebase 中の状態

詳細はgit rebase 使い方の記事も参照。

解決策③：git commit（変更を確定）

変更が完成していて、commit すべき状態なら:

# 1. commit
git add .
git commit -m "Add feature X"

# 2. pull（通常の merge か rebase）
git pull origin main

# 3. conflict あれば解決

メリット

• 明確な履歴が残る
• レビュー可能
• 後で取り消しやすい

デメリット

• 中途半端な状態でcommit すべきでない（WIP的な commit を残すと汚い）
• --fixup 等で後で整理する必要

中途半端な状態なら「WIP commit → 後で rebase」

# 一時的な commit
git commit -am "WIP: pull 前の退避"

# pull
git pull

# 後で rebase -i で修正
git rebase -i HEAD~3
# reword / squash / drop で整理

詳細はgit rebase 使い方の記事も参照。

解決策④：git restore / git checkout（変更を捨てる）

変更が不要なら、捨てるのが最速。

全ファイル

# Git 2.23+
git restore .

# または（古い書き方）
git checkout -- .

# 続いて pull
git pull origin main

特定ファイルだけ

git restore src/config.js
# または
git checkout -- src/config.js

メリット

• 一発で解決
• pull がすぐ動く

デメリット

• 変更が消える（復旧不可能な場合あり）
• 未commit なので reflog にも残らない

⚠️ 実行前に必ず確認

git status
git diff
# 本当に捨てていい変更か確認

未commit の変更は復旧が難しい。実行前の確認が重要。

詳細はgit reset vs revert vs restore の記事も参照。

解決策⑤：git reset –hard（強制リセット）

最強・最も乱暴な方法:

git reset --hard HEAD
git pull

動作

• HEAD 状態に強制的に戻す
• 未commit の変更を全て破棄
• Index、Working Tree ともにリセット

メリット

• 確実にリモートと同期できる状態になる

デメリット

• 未commit の全ての変更が消える
• リセット対象を絞れない

さらに強力：origin/main と完全一致

git fetch origin
git reset --hard origin/main

完全にリモートに合わせる。ローカルの commit 済み変更も消える（reflog で救済可能）。

⚠️ 最終手段。実行前に必ず状況確認。

詳細はgit reset vs revert vs restore の記事も参照。

5つの解決策 比較表

私の推奨

1. git pull --rebase --autostash を恒久設定（最強）
2. 迷ったら git stash（安全）
3. 完成なら commit（明確）
4. 不要なら restore（早い）
5. reset --hard は最終手段

実践シナリオ

シナリオ1：日常的な開発フロー

# 朝、開発開始
git status
# modified: src/user.js  ← 昨日の続き

# main を最新化したい
git pull
# error: Your local changes would be overwritten

# ✅ 解決
git pull --rebase --autostash
# 自動で stash → rebase → pop

シナリオ2：Stable Diffusion Web UI 更新（有名な例）

# webui-user.bat に git pull が入っている
cd stable-diffusion-webui
git pull
# error: Your local changes ... launch.py

# ✅ Stable Diffusion コミュニティで有名な解決策
git stash
git pull
git stash pop

# もし変更が不要なら（設定を変えただけ等）
git checkout launch.py
git pull

シナリオ3：緊急 hotfix（feature 作業中）

# feature 開発中
git status
# modified: src/feature.js（進行中）

# 緊急バグ対応でmain を pull したい
git stash push -u -m "feature WIP"
git checkout main
git pull

# バグ修正
vim src/fix.js
git commit -am "Hotfix"
git push

# 元の作業へ
git checkout feature
git stash pop

シナリオ4：CI/CD で発生

# .github/workflows/deploy.yml
- name: Checkout
  uses: actions/checkout@v4

- name: Pull latest
  run: git pull
# → error: local changes...

CI では通常発生しない（clean な環境）。発生する場合は checkout の設定を確認:

- uses: actions/checkout@v4
  with:
    fetch-depth: 0
    clean: true  # デフォルト true

シナリオ5：Rails 開発でのマイグレーション

# 未commit のマイグレーション
git status
# modified: db/schema.rb
# new file: db/migrate/xxx_add_column.rb

# main を pull したい
git pull
# error: db/schema.rb would be overwritten

# ✅ 解決
git stash push -u -m "migration WIP"
git pull
git stash pop

# schema.rb で conflict の可能性
# → migration を実行して schema.rb 再生成
bin/rails db:migrate
git add db/schema.rb
git commit

詳細はrails db:migrate 使い方の記事も参照。

シナリオ6：Solid Queue 設定変更中

# config/queue.yml を変更中
git status
# modified: config/queue.yml

# 最新の Solid Queue を pull したい
git pull --rebase --autostash
# 自動的に解決

詳細はSolid Queue 使い方の記事も参照。

シナリオ7：一時ファイル・設定変更を残したい

# .env（gitignored、tracked ではない）
# → merge の対象外なのでエラー出ない

# .env.example を変更中（tracked）
git status
# modified: .env.example

git stash
git pull
git stash pop

シナリオ8：Kamal デプロイ前の同期

# デプロイ前に main を最新化
git status
# 未 commit の変更あり

git stash push -u -m "before deploy"
git pull origin main
git stash pop

# conflict あれば解決
kamal deploy

詳細はKamal 2 デプロイの記事も参照。

シナリオ9：巨大な変更 + 大量のリモート更新

# 大きな作業中に大量のリモート更新
git status
# 数十ファイルが modified

# 慎重に対処
git stash push -u -m "big WIP $(date +%Y%m%d)"

# stash 内容確認
git stash show -p

git pull

# 段階的に戻す
git stash pop
# または部分的に
git checkout stash@{0} -- specific_file.js

シナリオ10：チームで頻発するので予防策

~/.gitconfig に設定を追加:

[pull]
    rebase = true

[rebase]

autoStash = true

[merge]

conflictStyle = diff3

[rerere]

enabled = true

これでチーム全員が自動的に適切な動作。

予防のベストプラクティス

1. こまめな commit

大きい変更を1つの commit にせず、論理的なまとまりで commit:

# 悪い
# 数日分の変更を溜め込み

# 良い
git commit -m "Add validation to user model"
git commit -m "Add tests for validation"

2. こまめな pull

朝一で:

git pull --rebase --autostash

放置するほどエラーの可能性が上がる。

3. pull.rebase を有効化

git config --global pull.rebase true
git config --global rebase.autoStash true

4. WIP branch の活用

未完成の作業は別ブランチに:

git checkout -b feature/wip-user-auth
# 自由に作業
git checkout main
git pull  # エラー出ない（別ブランチ）

5. stash を使う習慣

「pull する前に stash」を反射的に:

# alias 設定
git config --global alias.up '!git stash && git pull && git stash pop'
# → git up

6. .gitignore の見直し

tracked にすべきでないファイルを確認:

# 見直し候補
.env
node_modules/
tmp/
*.log

これらが tracked だとエラー多発。

7. IDE の自動フォーマット注意

保存時の自動フォーマットで意図せず全ファイルが modified に:

Prettier / Black / rubocop 等

pull 前に確認する習慣を。

トラブルシューティング

stash pop で conflict

git stash pop
# CONFLICT

# 通常の conflict と同じ対応
vim conflict_file
git add conflict_file

# ⚠️ pop で conflict 時、stash は自動削除されない
git stash drop

詳細はgit merge conflict の記事、git stash 使い方の記事も参照。

変更を捨てたつもりが残っている

git restore .
git status
# まだ変更が残ってる？

→ untracked ファイルは restore で消えない:

# untracked も削除
git clean -fd

# ⚠️ 確認してから
git clean -n  # dry-run
git clean -fd # 実行

git checkout -- . を実行したら消えた

未commit の変更は復旧不可能。教訓として学ぶ。

未来の予防:

• git stash を常用
• 危険操作前に git status / git diff で確認

大量の warning が出る

warning: LF will be replaced by CRLF

改行コード関連。動作には影響しないが気になる場合:

# Windows
git config --global core.autocrlf true

# macOS/Linux
git config --global core.autocrlf input

ファイルモード変更のみでエラー

git status
# modified: script.sh
git diff
# 中身は同じ、権限だけ変更

→ ファイルモードの検出を無効化:

git config core.fileMode false

CRLF/LF の混在

.gitattributes で管理:

* text=auto
*.sh text eol=lf
*.bat text eol=crlf

よくある質問（FAQ）

Q1. stash と commit、結局どっちが良い？

変更の完成度による:

• 完成 → commit
• 途中 → stash

「commit するには早い、でも消したくない」→ stash。

Q2. git pull --rebase --autostash の危険性

安全性は高い。conflict が発生した場合、rebase 中の状態になるため rebase の知識が必要。

初心者は普通の stash → pull → pop の方が理解しやすい。

Q3. git reset --hard 実行後の救済

Commit 済みなら reflog で救済可能:

git reflog
git reset --hard HEAD@{N}

未commit の変更は救済不可。

Q4. git stash した内容を確認

git stash list
git stash show -p stash@{0}

Q5. VS Code / IDE での対応

• VS Code: Source Control タブ → 変更を stash / discard
• JetBrains: Shelve or Commit
• SourceTree: Stash ボタン

または CLI で対応してから GUI 使用。

Q6. force pull できないの？

git fetch origin
git reset --hard origin/main

これが「force pull」相当。ローカルの変更は全て消える。

Q7. 特定ファイルだけ pull 対象外に

# .git/info/exclude に追加（gitignore と同じ形式）
echo "src/config.js" >> .git/info/exclude

または --assume-unchanged:

git update-index --assume-unchanged src/config.js

⚠️ 後で戻すのを忘れがち。危険。

Q8. tracked ファイルを untracked に

git rm --cached src/config.js
git commit -m "Untrack config.js"
echo "src/config.js" >> .gitignore

これで tracked から外れ、以後は変更しても影響なし。

Q9. 「stash に変更が入ってない」ように見える

untracked ファイルはデフォルトで stash 対象外:

# ❌
git stash
# untracked は残る

# ✅
git stash -u
# untracked も含める

Q10. GitHub Desktop / SourceTree での対応

• GitHub Desktop: 変更を Stash（右下）
• SourceTree: Stash ボタン
• 概念は CLI と同じ

Q11. git status に何もないのにエラー

git status
# nothing to commit

git pull
# error: local changes would be overwritten

→ ファイルモードの変更、または index の異常:

git checkout HEAD .
git pull

Q12. WSL / Windows の混在

改行コード or ファイル権限の問題。.gitattributes と core.fileMode false で対処。

参考リンク・関連資料

Git 公式

• git-pull Documentation – pull 公式
• git-stash Documentation – stash 公式
• git-rebase Documentation – rebase 公式

まとめ

Your local changes would be overwritten by merge の解決、要点を再整理します。

5つの解決策 比較

最速解決コマンド

# ⭐ 万能（変更維持 + 自動化）
git pull --rebase --autostash

# 手動でstash（丁寧）
git stash push -u -m "before pull"
git pull
git stash pop

# 変更を捨てて pull
git restore .
git pull

恒久設定（推奨）

git config --global pull.rebase true
git config --global rebase.autoStash true
git config --global rerere.enabled true
git config --global merge.conflictStyle diff3

これで自動的に解決されるように。

判断フロー

1. 変更を残したい？
   ├─ Yes → stash or commit or pull --rebase --autostash
   └─ No  → restore or reset --hard

2. 中身は完成？
   ├─ Yes → commit
   └─ No  → stash

3. 自動化したい？
   ├─ Yes → pull --rebase --autostash（恒久設定）
   └─ No  → 手動 stash

予防策

• こまめな commit
• こまめな pull
• pull.rebase = true の設定
• rebase.autoStash = true の設定
• WIP は別ブランチ
• .gitignore の見直し

事故防止

• git reset --hard の前: 必ず status/diff で確認
• stash pop 時 conflict: stash は自動削除されない → 手動 drop
• untracked ファイル: stash -u で明示
• 未commit の変更は復旧不可: 慎重に

覚えるべき最頻出コマンド

# 万能
git pull --rebase --autostash

# 一時退避
git stash push -u -m "message"
git stash pop

# 変更破棄
git restore <file>
git restore .

# 特定ファイルだけ捨てる
git checkout HEAD -- <file>

これらの知識は、日々の Git 操作・チーム開発・CI/CD・Rails/Docker 開発・Stable Diffusion 等のツール更新など、あらゆる場面で活用できます。本記事をブックマークしておけば、このエラーに出会っても5秒で最適な選択ができるようになります。

本記事は2026年6月時点の情報をもとに、Git 2.40+ での動作確認・公式ドキュメントに基づき作成しています。Git のバージョンによって挙動が異なる場合があるため、最新の情報はGit公式ドキュメントもあわせてご確認ください。