タイトル: error: Your local changes to the following files would be overwritten by checkout:
SEOタイトル: git『local changes would be overwritten by checkout』エラーの原因と解決
error: Your local changes to the following files would be overwritten by checkout:は、作業ツリーに未コミットの変更があるため、ブランチを切り替える（checkout / switch / pull）とその変更が上書きされてしまうとGitが判断し、操作を中断したことを示すエラーです。データ損失を防ぐための安全装置であり、変更を「確定（commit）」「退避（stash）」「破棄」のいずれかで片付ければ解決します。
| この記事の要点 |
|---|
|
エラーの意味 — なぜGitは切り替えを拒否するのか
このエラーは、次の2つの条件が同時に成立したときに発生します。
- 現在の作業ツリーにコミットしていない変更（編集途中のファイル）がある。
- その同じファイルに対して、切り替え先のブランチやpull先のコミットが異なる内容を持っている。
この状態でブランチを切り替えると、Gitは切り替え先の内容で作業ツリーのファイルを書き換えようとします。しかしそこには、まだどこにも記録されていないあなたの編集が乗っています。そのまま上書きすれば、編集内容は復元不可能な形で失われます。Gitはそれを未然に防ぐため、操作を実行せずに中断し、対象ファイルを一覧表示しているのです。
つまりこのエラーは「壊れている」のではなく、Gitが意図的にあなたの未保存の変更を守っている状態です。エラー後はブランチも切り替わっておらず、ファイルも一切変更されていません。慌てて破壊的なコマンドを打つ前に、まず落ち着いて対処方法を選びましょう。
具体的には、次のような典型的なメッセージが表示されます。
error: Your local changes to the following files would be overwritten by checkout: src/app.js Please commit your changes or stash them before you switch branches. Aborting |
メッセージ末尾の「commit your changes or stash them」がそのまま対処のヒントです。表示されたファイル名（上の例ではsrc/app.js）が、衝突している対象です。
最初にやること — 状況を確認する
解決手順に入る前に、どのファイルが未コミットなのかを必ず確認します。これを把握しておくと、後で「残すべき変更を誤って破棄する」事故を防げます。
git status |
変更内容そのものを確認したい場合は、差分を表示します。
git diff |
表示された変更が「残したいもの」か「要らないもの」かを判断したうえで、次の対処を選びます。
対処の選択肢 — 3つの方法を比較
解決方法は大きく3つです。変更を残したいかどうかで選ぶのが基本です。
| 方法 | 変更の扱い | 主なコマンド | 向いている場面 |
|---|---|---|---|
| ① 退避（stash） | 残す（一時退避→後で復元） | git stash → 切替 → git stash pop | 変更は残したいが、まだコミットしたくない。迷ったらこれ。 |
| ② 確定（commit） | 残す（履歴に記録） | git add → git commit | 変更がひと区切りつき、履歴に残してよい。 |
| ③ 破棄 | 消す（復元不可） | git restore / git checkout -- <file> | 変更は不要。試し書きや誤編集を捨てたい。 |
① 変更を一時退避する（git stash）— 最も安全
変更を残したいが、中途半端でコミットはしたくない場合に最適です。未コミットの変更を退避領域（stash）に逃がし、作業ツリーをきれいな状態に戻してからブランチを切り替えます。
# 1. 未コミットの変更を退避する git stash
# 2. 目的のブランチへ切り替える（例: develop） git switch develop
# 3. 退避した変更を戻す git stash pop |
git stash popは、退避した変更を作業ツリーに復元したうえで、その退避を一覧から削除します。退避を残したまま復元したい場合はgit stash applyを使い、退避一覧はgit stash listで確認できます。
なお、新規作成しただけでまだgit addしていないファイル（追跡対象外ファイル）は標準のgit stashでは退避されません。それらも含めたい場合はgit stash -uを使います。
② 変更をコミットする（git commit）
変更がひと区切りついていて、履歴に残してよい場合は、コミットしてから切り替えます。これが最もシンプルで、変更が確実に保存されます。
# 変更をステージに追加してコミット git add . git commit -m "作業内容の説明"
# その後ブランチを切り替える git switch develop |
「まだ正式なコミットにはしたくないが、とりあえず記録は残したい」という場合は、後でgit commit --amendやgit reset --soft HEAD^でやり直せます。気軽にコミットしておき、後で整理する運用も有効です。
③ 変更を破棄する — 不要なときだけ
編集が試し書きや誤操作で、残す価値がないと確認できた場合のみ、変更を破棄して解決します。破棄した内容はGitの履歴にもstashにも残らず、原則として元に戻せません。実行前に必ずgit statusとgit diffで「本当に捨ててよいか」を確認してください。
特定のファイルだけ破棄する場合（Git 2.23以降推奨のrestore）。
# 指定ファイルの未コミット変更を破棄 git restore <file> |
古いGitや従来の書き方では、次のコマンドが同等です。
git checkout -- <file> |
エラーに表示された全ファイルの変更をまとめて破棄したい場合は、対象を指定します。
# カレント以下の追跡ファイルの変更をすべて破棄 git restore . |
どれを選ぶべきか
- 変更を残したい・後で続きをやりたい → ① git stash。コミットの粒度を気にせず一旦逃がせるので、最も使い勝手がよく安全です。
- 変更がひと区切りついた・履歴に残してよい → ② git commit。確実に保存され、後からの整理も効きます。
- 変更が完全に不要 → ③ 破棄。ただし復元できないので、確認のうえ慎重に。
判断に迷ったときは①のstashを選んでおけば、まず損をしません。「とりあえず逃がして、後で考える」が安全な進め方です。
落とし穴と注意点
| 操作・状況 | 何が危険か |
|---|---|
git checkout . / git restore . | 未コミット変更をまとめて完全削除する。「checkoutで切り替えればよい」と誤って打つと作業内容を失う。 |
git reset --hard | 作業ツリーとステージの変更をすべて破棄する破壊的操作。エラー解消目的で安易に使わない。残したい変更があるなら絶対に避ける。 |
git stash pop時のコンフリクト | 退避中に切替先で同じ箇所が変わっていると、復元時に競合が起きる。popは競合時に退避を消さないので、競合解決後にgit stash dropで手動削除する。 |
git clean -fdの併用 | 追跡対象外の新規ファイルを問答無用で削除する。このエラーの解消には通常不要。実行前にgit clean -nd（ドライラン）で対象を確認する。 |
| 破棄系コマンドの取り消し期待 | 破棄した未コミット変更はgit reflogでも追えない。コミットやstashと違い復元手段がないと考える。 |
git pull で同じエラーが出る場合
ブランチ切り替えだけでなく、git pullでもこのエラーが出ることがあります。pullはリモートの変更を取り込む際に作業ツリーを更新するため、未コミットの変更と衝突するからです。対処は同じで、pull前にgit stashで退避するか、git commitで確定しておきます。
git stash git pull git stash pop |
よくある質問（FAQ）
Q1. このエラーが出た時点で、私の変更はもう消えてしまったのですか？
いいえ。Gitは操作を中断しただけで、ファイルもブランチも一切変更していません。作業ツリーの未コミット変更はそのまま残っています。安心して、commit・stash・破棄のいずれかを選んでください。
Q2. git stash popでコンフリクトが出ました。どうすればいいですか？
退避した変更と現在のブランチの内容が同じ箇所で衝突しています。コンフリクトマーカー（<<<<<<<など）が入ったファイルを手動で編集して解決し、git addで確定します。popは競合時に退避を削除しないため、解決後にgit stash dropで退避一覧から取り除いてください。
Q3. 変更を残しつつ、別ブランチでまったく別の作業をしたいのですが？
git stashで退避してから切り替えるのが基本です。複数の作業を同時並行したい場合は、退避ではなくgit worktreeで作業ディレクトリを分ける方法もあります。1つのリポジトリを複数のディレクトリにチェックアウトでき、ブランチごとに環境を分離できます。
Q4. 切り替え前に毎回このエラーで困らないための予防策は？
ブランチを切り替える前にgit statusを確認する習慣をつけ、作業の区切りでこまめにコミットするのが最も効果的です。中断時にはstashで逃がしておけば、未コミットの変更が衝突する場面を大きく減らせます。