Gitでの作業中に「変更を一時的に退避したい」と思った経験はありませんか？そんなときに便利なのが「git stash」ですが、せっかく退避した変更を元に戻す操作で戸惑ったり、どのコマンドを使えば安全なのか分からず不安になることも多いでしょう。特に「git stash pop」と「git stash apply」の違いや、間違って削除してしまったときの復旧方法、競合が発生した場合の対処法などはよくある悩みです。
この記事では、git stashで退避した変更を安全に戻すための基本的な手順から、特定のファイルだけ戻す応用テクニック、トラブルが起こりやすい場面での対処法まで幅広く解説します。初心者の方でも理解しやすいよう丁寧に説明しつつ、実務で使える知識とコマンド例を豊富に紹介していますので、git stashの使い方に自信がない方も安心して読み進められます。
この内容を押さえることで、git stashの扱いに自信が持て、作業効率と安全性が格段に向上します。ぜひ最後までご覧ください。
格安ドメイン取得サービス─ムームードメイン─
git stashで退避した変更を安全に戻す基本手順
日々の開発でgit stashは非常に強力なツールですが、「退避はできたけど、戻すのが怖い…」と感じたことはありませんか？特に、緊急の修正やブランチ切り替えのために一時的に変更を隠したとき、その変更を安全かつ確実に元の状態に戻すことが重要です。このセクションでは、git stashで退避した変更をメインのブランチに「失敗せずに」戻すための基本と手順を、実践的なコマンド例とともに徹底解説します。
git stashの基本的な使い方と適用手順（git stash apply / pop）
git stashは、まだコミットしたくない作業中の変更（ステージングされていないものとステージングされたもの）を一時的に「棚上げ（stash）」する機能です。これにより、クリーンなワーキングツリー（作業ディレクトリ）に戻り、別の作業（ホットフィックスなど）に集中できます。変更を戻す際には、主にgit stash applyとgit stash popという2つのコマンドを使います。
git stash apply
これは、退避した変更を現在のブランチに適用（戻す）するコマンドです。適用後も、スタッシュリスト（棚）には変更内容が残ったままになります。
メリット: 変更を適用する前に、万が一の失敗に備えてスタッシュ内容をバックアップとして残しておきたい場合に適しています。
# 最新のスタッシュ（stash@{0}）を適用する
git stash apply
git stash pop
これは、退避した変更を現在のブランチに適用し、同時にスタッシュリストからその変更を削除するコマンドです。
メリット: 変更が元のブランチに完全に統合され、スタッシュリストがクリーンになるため、一時的な作業を終えたときに最も一般的に使われます。
# 最新のスタッシュ（stash@{0}）を適用し、スタッシュリストから削除する
git stash pop
これらのコマンドを実行する際は、必ず適用したい変更を退避したブランチ、あるいは同じベースのブランチにいることを確認しましょう。異なるブランチに適用することも可能ですが、コンフリクト（競合）のリスクが高まります。
最も簡単なコマンドでstashを元のブランチに戻す方法
ほとんどの場合、あなたが最後にgit stashした変更を、すぐに元の作業に戻したいというケースでしょう。この「最後の変更を戻す」という操作は、git stash popを使うのが最もシンプルで効率的です。
# 実行例：作業中の変更を退避
git add .
git stash save "Feature-A開発中の緊急退避"
# 別の作業（hotfix）を完了後、元のブランチに戻って...
# 最も簡単な方法で最後の変更（stash@{0}）を戻す
git stash pop
このコマンドを実行すると、Gitは以下の処理を自動で行います。
Git内での処理
- スタッシュリストの最新の項目（通常は
stash@{0}）を見つける。 - そのスタッシュに含まれるステージングされた変更とステージングされていない変更を、現在のワーキングツリーに適用しようと試みる。
- 適用に成功した場合、スタッシュリストからその項目を削除する。
もし適用時にコンフリクト（競合）が発生した場合は、git stash popはスタッシュの削除を行わず処理を中断します。これにより、コンフリクト解消後に再チャレンジできるよう、データロストを防ぐセーフティネットが働きます。初めて使う方は、まずはgit stash popから使い始め、その挙動に慣れることをお勧めします。
stash内容を確認してから戻す方法（git stash list / git stash show / git diff）
安全にスタッシュを戻すには、「何が戻ってくるのか」を事前に把握しておくことが非常に重要です。複数のスタッシュがある場合や、しばらく時間が経って内容を忘れてしまった場合に特に有効です。
退避されているスタッシュの一覧を確認する: git stash list
まず、現在退避されているスタッシュがいくつあるか、それぞれの簡単なメッセージを確認します。
git stash list
# 出力例:
# stash@{0}: On feature/A: Feature-A開発中の緊急退避
# stash@{1}: On master: 別の作業のための退避
この結果から、戻したいスタッシュがstash@{0}なのか、stash@{1}なのかといったインデックス（識別子）を確認できます。
スタッシュの内容を簡単に確認する: git stash show
次に、特定のスタッシュが「どのファイルを変更していたか」を簡単に確認します。デフォルトでは、最新のスタッシュstash@{0}が表示されます。特定のスタッシュを見たい場合は、インデックスを指定します。
# 最新のスタッシュの内容を概要表示
git stash show
# stash@{1}の内容を概要表示
git stash show stash@{1}
# 変更内容（diff）を詳細に確認したい場合
git stash show -p
# または
git stash show -p stash@{1}
オプション-p（または--patch）を付けると、変更内容の差分（diff）をコードレベルで詳細に確認できます。これが最も安全に内容を確認する方法であり、「何を戻そうとしているか」を明確に理解するために必須のステップです。
スタッシュを戻すコマンド
内容を確認し、問題がないと判断できたら、以下のコマンドで安全に戻します。特定のスタッシュを戻すには、popまたはapplyの後にインデックスを指定します。
# stash@{1}の内容を適用し、スタッシュリストから削除する
git stash pop stash@{1}
# stash@{0}の内容を適用し、スタッシュリストに残す
git stash apply stash@{0}
このように、listでインデックスを確認し、show -pで内容を精査してからpopやapplyで適用することで、意図しない変更が紛れ込むリスクを最小限に抑えられます。
git stash pop・applyの違いと使い分け
git stashで退避した変更を戻す際、最初に直面する選択がpopを使うかapplyを使うかです。この選択は、単なる機能の違いだけでなく、データ保持の考え方やワークフローの安全性にも関わってきます。このセクションでは、それぞれのコマンドの厳密な違いと、チーム開発や緊急時のシチュエーションに応じた適切な使い分けについて解説します。
git stash popとapplyの違い／使いどころ比較
| 特徴 | git stash pop | git stash apply |
|---|---|---|
| スタッシュの残り方 | 適用後、スタッシュリストから削除される | 適用後も、スタッシュリストに残る |
| 使用目的 | 一時的な作業を「完了」させ、ワーキングツリーに統合するとき | 適用前に内容を試したいとき、バックアップを残したいとき |
| データロストのリスク | 低い（適用失敗時は残る）が、成功時は消えるため注意が必要 | 非常に低い（常に残るため） |
| 推奨される場面 | 変更を完全に元に戻す（ブランチに戻す）ことが目的の標準的な運用 | 複数のブランチで同じ変更を試したい、または慎重に適用したい緊急時 |
git stash pop（使い捨て、標準運用）
popは「取り出して、捨てる」というイメージです。変更を現在のブランチに適用し、スタッシュリストからそのアイテムをクリーンアップします。これは、一時的な作業を終え、元のブランチで開発を再開する最も一般的なケースで推奨されます。
# 適用と同時にスタッシュリストから削除
git stash pop
git stash apply（再利用可能、慎重運用）
applyは「適用する」という文字通りの意味で、変更をワーキングツリーに戻しますが、スタッシュリストにはアイテムを残したままにします。これは、退避した変更を別のブランチでも試したい場合や、変更を適用する前に「もしコンフリクトしたらすぐに復元したい」といった保険をかけたい場合に非常に有効です。
# 適用後もスタッシュは残る（後で別のブランチに再適用したり、手動でdropできる）
git stash apply
運用上、特別な理由がない限りはgit stash popでリストを整理する習慣をつけると、後で「どのスタッシュがまだ必要か？」と迷うことが少なくなります。
pop・apply実行後の「取り消し」方法と復旧の手順
popやapplyを実行したものの、「やっぱりこの変更は戻したくなかった」と後悔することもあるかもしれません。特にpopを使った場合、スタッシュリストから消えてしまうため、迅速な対応が必要です。
スタッシュ適用後の「取り消し」は、基本的にgit resetまたはgit restoreコマンドを用いて行います。
ステップ1: 適用された変更を把握する
まず、popまたはapplyによってワーキングツリーに適用された変更の内容（ファイル単位）を**git status**で確認します。
ステップ2: 適用前の状態に戻す
スタッシュ適用前の状態（つまり、pop/apply実行直前のコミットの状態）に戻すには、主に以下の2つの方法があります。
変更内容を破棄し、コミットの状態に戻す (git restore)
特定のファイルだけを元の状態に戻したい場合に最適です。
# ワーキングツリーの変更をすべて破棄し、HEADの状態に戻す
git restore .
# または、特定のファイルのみ破棄
git restore path/to/file.js前回のコミットまでリセットする (git reset –hard)
ワーキングツリーのすべての変更を破棄し、コミット履歴も強制的に特定のコミットに戻します。スタッシュ適用後に何もコミットしていない場合に有効ですが、非常に強力なコマンドなので慎重に使ってください。
# 直前のコミット（HEAD）の状態に強制的に戻す
git reset --hard HEAD注意点: git reset --hardは、適用されたすべての未コミットの変更を完全に破棄します。popでスタッシュも消えている場合、データは事実上ロストします。不安な場合は、git restoreでファイルごとに破棄することをお勧めします。
stashを残したまま適用したい場合の注意点
git stash applyを使ってスタッシュを残したまま適用する運用は非常に便利ですが、リストが肥大化しやすいという欠点があります。
1. リストの肥大化と管理の複雑化
applyを繰り返すと、不要になった古いスタッシュがリストに残り続けます。これにより、git stash listが長くなり、「本当に必要なスタッシュはどれか？」という管理が複雑になります。
対策: 適用後に不要になったスタッシュは、手動でgit stash dropを使って削除する習慣をつけましょう。
# 2番目のスタッシュ（stash@{1}）を削除する
git stash drop stash@{1}
2. コミットハッシュの参照（特にコンフリクト時）
git stashは、実際には2つ以上の特殊なコミットを作成し、それを参照しています。applyを使ってスタッシュを残した場合、万が一、後でコンフリクトが発生した際に、stash@{N}という一時的な参照が、競合解消の作業中も残り続けます。この参照が残っていることで、後からgit diffなどで元のスタッシュ内容と比較するデバッグ作業に役立つ場合があります。
注意点: applyで適用後、すぐにgit commitを行って変更を確定させることが、作業を安全に進めるための鉄則です。適用した変更がワーキングツリーに未コミットの状態で残っていると、次の作業で誤ってgit reset --hardなどを使って消してしまうリスクが高まります。
特定のstashやファイルだけを戻す応用テクニック
git stash popやgit stash applyで最新のスタッシュを丸ごと適用するだけでなく、過去のスタッシュや、スタッシュ内の特定のファイルだけを選択的に戻したい場面は頻繁に発生します。これは、より複雑なワークフローや、スタッシュに意図しない変更が混ざってしまった場合に「安全に必要なものだけ」を取り出すために必須のテクニックです。このセクションでは、スタッシュをより柔軟に、ピンポイントで利用するための応用コマンドを解説します。
過去のstashから特定のものだけを戻す方法（stash@{1}など）
スタッシュリストには複数の退避が積み重なっていることがあります。最新のstash@{0}ではなく、過去に退避した特定のスタッシュ（例：stash@{1}やstash@{2}）を戻したい場合は、コマンドの末尾にそのスタッシュの識別子を指定するだけです。
1. 識別子を確認する
まず、git stash listで目的のスタッシュの識別子を確認します。
git stash list
# 出力例:
# stash@{0}: On feature/B: B機能の途中
# stash@{1}: On feature/A: A機能の初期段階 <--- これを戻したい
# stash@{2}: On master: 緊急時の退避
2. 特定のスタッシュを適用する
識別子を確認したら、それをpopまたはapplyコマンドの引数として渡します。
# stash@{1}の内容を適用し、スタッシュリストから削除する（pop）
git stash pop stash@{1}
# stash@{2}の内容を適用し、スタッシュリストに残す（apply）
git stash apply stash@{2}
重要な注意点: 特定のスタッシュをpopで削除すると、スタッシュリストの他のスタッシュの識別子（stash@{0}、stash@{1}など）が繰り上がって変更されることに注意してください。例えば、stash@{1}をpopで削除すると、元々stash@{2}だったものが新しいstash@{1}になります。続けて別のスタッシュを操作する場合は、必ず**git stash listで再確認**してから実行しましょう。
コストパフォーマンスに優れた高性能なレンタルサーバー
【Hostinger】
特定のファイルだけをstashから戻す手順
スタッシュに退避した大量のファイルのうち、特定のファイル（またはディレクトリ）だけを現在のワーキングツリーに戻したい場合があります。この操作は、**git checkout**コマンドに似た構文を使って行います。
1. ファイルパスを確認する
git stash show -pを使って、目的のファイルがスタッシュに含まれているか、またその正確なファイルパスを確認します。
2. 特定のファイルを取り出す
スタッシュの識別子とファイルパスを組み合わせてgit checkoutコマンドを実行します。
# 特定のスタッシュ（stash@{1}）から特定のファイルを取り出す構文
git checkout <stashの識別子> -- <ファイルパス>
# 実行例: stash@{1}から src/api/user.js だけを取り出す
git checkout stash@{1} -- src/api/user.js
# 実行例: 最新のスタッシュ（stash@{0}）から services/ のディレクトリ全体を取り出す
git checkout stash@{0} -- services/
この操作はgit checkoutを使用しますが、これは実際にはスタッシュのコミットからファイルをコピーしているため、スタッシュリストのアイテム自体は一切変更されません。つまり、この操作はapplyのように機能し、スタッシュは残ったままになります。複数のファイルが必要な場合も、上記のようにコマンドの末尾にスペース区切りでファイルパスを列挙できます。
戻した変更を再び取り消す方法（git reset・git restore活用）
特定のスタッシュやファイルを戻した後、「やっぱりこれは不要だった」と、戻した変更自体を取り消し、ワーキングツリーをスタッシュ適用前の状態に戻したいことがあります。この操作は、前のセクションでも触れましたが、データロストのリスクを避けるため、git stashの基本操作とは切り離して理解しておくべき重要な復旧テクニックです。
スタッシュを適用した後の変更は、未コミットの変更としてワーキングツリー（作業ディレクトリ）に残っています。これを取り消すには、以下のコマンドを使います。
1. ワーキングツリーの変更を取り消す (git restore)
最も安全な方法は、git restoreを使用して、特定のファイルを前回のコミットの状態に戻すことです。
# 戻した変更のうち、特定のファイルだけを破棄
git restore path/to/file.js
# ワーキングツリーにある、すべての未コミットの変更を一括で破棄
git restore .
このコマンドは、git stash apply（またはpop）で戻された変更だけでなく、それ以降に手動で加えたすべての未コミットの変更も破棄します。意図したファイルパスを正確に指定し、破棄する前にgit statusで状況を確認してください。
2. ステージングされた変更も同時に取り消す (git reset)
もしスタッシュから戻した後に、その変更をgit addでステージングしてしまった場合は、git resetでステージング状態を解除する必要があります。
# ステージングされている（git add された）変更を解除
git reset HEAD -- path/to/file.js
git reset HEADは変更をワーキングツリーに残すため、データロストの心配はありません。ステージングを解除した後に、上記git restoreコマンドで完全に変更を破棄できます。
戻す操作で起こりやすいトラブルと安全な運用方法
git stashの操作、特に変更を「戻す」ときには、コンフリクト（競合）の発生やデータの意図しないロストといったトラブルがつきものです。これらの問題は、作業効率を大幅に低下させるだけでなく、最悪の場合、開発履歴を混乱させる原因にもなりかねません。このセクションでは、現場で遭遇する可能性が高いトラブルに焦点を当て、具体的な安全な解決手順と、チーム開発におけるベストプラクティスを徹底解説します。
競合（コンフリクト）が発生した場合の安全な解消手順
git stash popやgit stash applyを実行した際に、現在のブランチとスタッシュの内容が同じファイル（同じ行付近）を変更していると、Gitは自動的に統合できず、コンフリクトが発生します。
1. コンフリクトの発生と状況確認
コンフリクトが発生すると、ターミナルには以下のようなメッセージが表示されます。
# git stash pop 実行後...
error: Your local changes to the following files would be overwritten by merge:
src/features/product.js
Stashing failed. Try running "git stash drop" (if that's what you want).
または、popやapplyが試みられた結果、特定のファイルに競合マーカーが挿入されます。
2. 安全な解消手順（ステップ・バイ・ステップ）
コンフリクトファイルの確認:
git statusを実行し、どのファイルでコンフリクトが発生しているかを確認します。
ファイルの編集:
競合が発生したファイルを開き、<<<<<<<, =======, >>>>>>>といった競合マーカーを手動で編集します。
<<<<<<< HEADから=======まで：現在のブランチの変更- ======= から >>>>>>> まで：スタッシュから戻そうとした変更 この両方の変更を確認し、最終的に採用したいコードに手動で修正します。
コンフリクトの解消をマーク（ステージング）:
ファイルを修正したら、git addコマンドでそのファイルをステージングし、「このファイルは競合解消済みである」とGitに伝えます。
# 修正したファイルをステージング
git add src/features/product.jspopの再実行（applyの場合）またはコミット（popの場合）:
applyを使った場合：
コンフリクト解消後、git commitを行って変更を確定させ、git stash dropで手動でスタッシュを削除します。popを使った場合：
コンフリクトが発生すると、popはスタッシュの削除を中断します。そのため、競合解消（git add）後、git commitを行って変更をコミットで確定させることで、作業は完了です。popが削除を中断しているため、手動でgit stash dropを行う必要はありません。
git stash dropやgit stash clearで消した内容を復旧できるか？
結論から言うと、復旧は可能ですが、時間との戦いになります。git stashは、実態としては特別なコミットとしてGitのデータベース（オブジェクトストア）に保存されています。dropやclearは、このコミットへの参照（Ref）を削除するだけで、コミットオブジェクト自体を直ちには削除しません。
復旧のための知識：Reflogの活用
Gitは、過去にHEADが指していた場所や、スタッシュ参照の変更履歴をReflog（リファレンスログ）という仕組みで一定期間保持しています。
Reflogの確認:
dropやclearを実行する直前のスタッシュのコミットハッシュをReflogから探します。
# すべての参照の変更履歴を表示
git reflog出力の中から、スタッシュ操作に関連する行を探します。例えば、stash@{0}のような参照が最後に指していたコミットハッシュ（例：a1b2c3d）を見つけます。
ブランチの作成による復旧:
見つけたコミットハッシュを使って、新しいブランチを作成することで、スタッシュの内容を復活させることができます。
# ハッシュ 'a1b2c3d' の内容から 'recovering-stash' ブランチを作成
git checkout -b recovering-stash a1b2c3d注意点: Reflogはデフォルトで約30日間で古い参照を削除します。また、Garbage Collection（GC）が実行されると、参照されていないオブジェクトは完全に削除されます。そのため、データロストに気づいたら、できるだけ早くこの手順を実行する必要があります。
新世代レンタルサーバー『シンレンタルサーバー』
チーム開発で安全にstashを使うベストプラクティスと運用フロー
チーム開発では、スタッシュの使い方一つで共同作業の効率が大きく変わります。安全性を確保し、誤解を避けるための運用フローを確立しましょう。
明確なスタッシュメッセージを付ける:
git stash save “メッセージ”またはgit stash push -m “メッセージ”を必ず使用し、「何の作業を、なぜ退避したのか」を明確に記述します。メッセージがないと、他のメンバー（または数週間後の自分）にとって、そのスタッシュが「ゴミ」なのか「重要」なのか判別できなくなります。
# 良い例：目的と内容が明確
git stash push -m "Feature X (WIP): Auth logic - before switching to hotfix Y"git stash popを基本とする:
特別な理由がない限り、applyではなくpopを使用し、スタッシュリストを常にクリーンに保つことを推奨します。リストが短いほど、管理ミスや誤ったスタッシュの適用を防げます。
Untrackedファイルを含めるか明示する:
スタッシュはデフォルトで未追跡（Untracked）ファイルを含みません。退避が必要な場合は、-uまたは–include-untrackedオプションを明示的に使用するようにチーム内で統一します。
# 未追跡ファイルもまとめて退避
git stash push -u -m "Includes new config files"ブランチを跨いだstashの利用を避ける:
原則として、スタッシュを作成したブランチでスタッシュを戻すようにします。異なるブランチで適用すると、ファイルのベースライン（基準となるコミット）が異なり、コンフリクトのリスクが大幅に高まるからです。どうしても必要なら、applyで試行し、成功後に手動でdropするフローを徹底しましょう。
専門的な知識不要！誰でも簡単に使える『XWRITE(エックスライト)』
よくある質問（FAQ)
-
git stashの変更を別のブランチに戻しても大丈夫ですか？ 他のブランチに影響はありますか？ -
戻すことは可能ですが、慎重に、そして基本的に影響はありません。
git stashで退避された変更は、特定のブランチに紐付いているわけではありません。スタッシュはGitのデータベースに単に保存されるだけで、どのブランチからもアクセス・適用が可能です。影響について:
スタッシュを適用する際、その変更は現在のブランチのワーキングツリーに反映されるだけで、他のブランチの履歴やコードには一切影響を与えません。他のブランチが知らない間に勝手に書き換わることはありませんので、ご安心ください。
推奨される使い方:
ただし、異なるブランチにスタッシュを適用すると、元のブランチとの変更の基準点（ベース）が大きく異なるため、競合（コンフリクト）が発生する可能性が非常に高まります。特別な理由がない限りは、スタッシュを作成したブランチ、またはそのブランチの最新のコミットをmergeやrebaseで取り込んだ最新の状態のブランチに戻すことを強く推奨します。
-
過去にコミットした内容をgit stashで退避・戻すことはできますか？
-
いいえ、できません。
git stashが退避できるのは、「まだコミットしていない」作業ディレクトリ（ワーキングツリー）とステージングエリアの変更のみです。コミット済みの変更の扱い:
すでにgit commitした変更は、ブランチの履歴の一部となり、スタッシュの範疇ではありません。コミット済みの変更を取り消したい場合は、git revert（取り消しコミットを作成）やgit reset（履歴の変更）といった別のコマンドを使用する必要があります。
応用的な使い方:
ただし、コミット済みの変更を一時的に「取り消して」別の作業をしたい場合は、まずgit reset HEAD^などでコミットを取り消して未コミットの状態に戻し、その後にgit stashで退避するという応用的なワークフローは可能です。
-
スタッシュを戻すときに、ステージングされていた変更（git addしたもの）はどうなりますか？
-
ステージングされていた変更も一緒に戻ってきますが、ステージング状態は保持されません。
git stashを実行すると、通常、ワーキングツリーの変更だけでなく、git addでステージングされていた変更も一緒に退避されます（これがデフォルトの挙動です）。
スタッシュをpopまたはapplyで戻す際、退避時にステージングされていた変更もワーキングツリーに戻ってきますが、戻ってきた変更はすべて「ステージングされていない」状態（Unstaged）になります。
注意点:
もし、退避した際のステージング状態を完全に再現したい場合は、以下のコマンドを使用します。
# スタッシュを適用する git stash apply # 退避時のステージング状態を再現する（スタッシュは通常、ステージング状態を保存したコミットを持っています） git stash apply --index-indexオプションを使用すると、退避時にgit addされていた変更が、適用後もステージングされた状態（Staged）として復元されます。これは非常に便利なテクニックですが、コンフリクトが発生した場合、再現に失敗する可能性があるため注意が必要です。
まとめ
この記事では、git stashで退避した変更を安全かつ確実に「戻す」ためのテクニックを網羅的に解説しました。基本的なpopとapplyの違いから、トラブル時の復旧方法、さらにはチーム開発でのベストプラクティスまで、「これを見れば全て解決する」という状態を目指しました。
git stashは、ブランチの切り替えや緊急対応をスムーズにする強力なツールです。この記事で学んだ知識を活かし、安全かつ効率的な開発ワークフローを確立してください。これらの応用テクニックと安全対策を身につければ、もうgit stashの操作で不安を感じることはなくなるでしょう。
