git スタッシュ — ただのパニック保存を超える（部分スタッシュ、名前付きスタッシュ、その他）

あなたは学びました git stash 慌てて。誰かが機能の途中であなたに通知を送り、すぐにブランチを切り替える必要があり、スタッシュが最も迅速な解決策でした。その日を救いました。

その後、3つのスタッシュを持ち、その内容を忘れて、間違ったものを間違ったブランチに適用し、スタッシュが壊れていると決めました。それは壊れていない。あなたがいくつかのコマンドを習得するだけでいいのです。

未追跡ファイルがキャッチする（最初にこれを読む）

git stash のみ保存 追跡された ファイル — Gitが既に知っているファイル。まだステージされていない新しいファイルはGitにとって見えません。

# You created a new file mid-feature
echo "temp work" > new-feature.js

git stash
# new-feature.js is still sitting there — stash ignored it entirely

追加する -u 未追跡ファイルを含めるために：

git stash push -u

また、 -a (--all) は無視されたファイルも含みます。それはほとんどあなたの望まないものです — それはあなたの node_modules 変更と .env ファイルをスタッシュし、復元を難しくします。

スタッシュを名前をつけて、後悔しないように

デフォルトのスタッシュメッセージは：

stash@{0}: WIP on main: a3f1c2d Update dependencies

3つの異なる半完成の機能から3つのスタッシュがあるとき、これは意味がありません。名前をつけるために git stash push -m を使用してください：

git stash push -u -m "wip: oauth token refresh flow"
git stash push -u -m "experiment: lazy load images on scroll"
git stash push -u -m "fix: header z-index issue"

現在 git stash list これは実際に読みやすいです：

stash@{0}: On main: fix: header z-index issue
stash@{1}: On feature/images: experiment: lazy load images on scroll
stash@{2}: On feature/auth: wip: oauth token refresh flow

特定の一つをインデックスで適用する：

git stash apply stash@{2}   # brings back the auth work

適用する前に確認：stash show -p

git stash show 変更されたファイルの要約を提供します。追加で -p を追加すると、完全な差分が得られます：

git stash show -p stash@{2}

これは多くの人がスキップして後悔するコマンドです。これがないと、あなたはスタッシュされた変更を、あなたがスタッシュした時点から大きく変化したブランチに無意識に適用します。すばやく show -p を実行すると10秒で、あなたが適用する内容を正確に知ることができます。

スタッシュの差分を現在のファイルの状態と並列に比較したい場合、両方を テキスト比較 ツールに貼り付けてください — ヘッドで整理するよりも速いです。 git diff stash@{N}..HEAD -- path/to/file です。

適用とポップの違い：実際に重要な違い

どちらのコマンドもスタッシュを復元します。重要な違いは次の通りです：

• git stash pop =適用 + スタッシュエントリを削除
• git stash apply =適用し、スタッシュエントリを保持

もし pop に到達し、マージコンフリクトが発生すると、Gitは解決する前にスタッシュエントリを削除します。その結果、コンフリクトのあるワークツリーを持ち、スタッシュの参照がありません。

apply コンフリクトを解決する間、エントリを保持し、その後手動でクリーンアップします：

# Safer workflow when conflicts are possible
git stash apply stash@{0}
# resolve any conflicts
git stash drop stash@{0}   # explicit cleanup once you're happy

この追加 drop ステップは、スタッシュが数時間の作業を表す場合に価値があります。

部分スタッシュ（–patch）

場合によっては、あなたの変更の一部だけをスタッシュしたいことがあります。同じファイルにバグ修正と半分の新機能があり、修正をコミットしつつ、機能コードをスタッシュしたい場合です。

git stash push --patch （または -p) は、ヒンクごとにインタラクティブなセッションを開きます：

git stash push -p -m "wip: new feature half"

各ヒンクに対して、あなたは同じ y/n/s/q インターフェースを得ます。 git add -pをタイプすることで、Gitの自動分割が細かすぎない場合、ヒンクを小さなピースに分割できます。これは単純なスタッシュよりも遅いですが、汚れたワークツリーを分割するための最もクリーンな方法であり、一時的なブランチを作成せずに済みます。 s 一つの注意点：

モードは未追跡ファイルを含みませんので、 --patch と組み合わせることはできません。あなたがスタッシュしている機能に含まれる新しい未追跡ファイルがある場合、それらを -uして、追跡されたものに変更し、その後部分スタッシュを実行する必要があります。 git add それらを

実際の使用例

機能の途中でコンテキストの切り替え。 レビュアーが別のPRに対して急ぎのフィードバックを残し、あなたはまだ未完成のコードに深く没頭しています。名前をつけてスタッシュし、ブランチを切り替え、レビューを行い、戻ってポップします。WIPコミットやブランチの操作が不要です。

git stash push -u -m "wip: refactor auth middleware"
git checkout fix/urgent-prod-bug
# ... review and fix ...
git checkout feature/auth-refactor
git stash pop

クリーンなテスト実行の確認。 テストがクリーンなワークツリー上で通過することを確認したい — 半完成の変更がテスト環境に漏れることを防ぐために：

git stash push -u
npm test          # or pytest, cargo test, whatever
git stash pop

これは、テストがローカルの変更によって通過する場合をキャッチします。共有テストファイクスを持つリポジトリでは、より頻繁に起こります。

コンフリクトのある汚れたワークツリーでブランチを切り替える。 Gitは、ワークツリーに変更がある場合、その変更が上書きされる可能性があるため、ブランチをチェックアウトしないと拒否します。まずスタッシュし、ブランチを切り替え、スタッシュを取り戻します。単に git commit --fixup でブランチを移動するよりも速いです。

git stash シート

コマンド	プレビューカードに表示される見出し
git stash push	追跡された変更をスタッシュ（ショートハンド： git stash)
git stash push -u	未追跡ファイルを含める
git stash push -m "name"	説明的な名前でスタッシュ
git stash push -u -m "name"	未追跡＋名前（最も使われる組み合わせ）
git stash push -p	インタラクティブな部分スタッシュ（ヒンクごと）
git stash list	すべてのスタッシュをリスト表示
git stash show stash@{N}	スタッシュ内の変更ファイルの要約
git stash show -p stash@{N}	スタッシュの完全な差分
git stash apply stash@{N}	スタッシュを適用し、エントリを保持
git stash pop	最も最近のスタッシュを適用し、エントリを削除
git stash drop stash@{N}	特定のスタッシュエントリを削除
git stash clear	すべてのスタッシュエントリを削除
git stash branch <branchname>	スタッシュから新しいブランチを作成し、適用する

スタッシュブランチのエスケープハッチ

もう一つ知っておくべきコマンド： git stash branch <branchname>。これは、あなたがスタッシュした時点のコミットに新しいブランチを作成し、スタッシュを適用し、適用がクリーンであればそれを削除します。あなたのスタッシュされた変更が大きくて、独自のブランチに値する場合に正しい選択です — そして、コンフリクト問題を完全に回避します。なぜなら、あなたはそのスタッシュが元になった正確なツリー上でそれを再実行しているからです。

90%のスタッシュの痛みを解決する習慣：すべてを -mで名前をつけて、変更がクリーンに統合されるまで apply の代わりに pop まで使用します。この追加 drop ステップは2秒です。必要なスタッシュを失うことは、はるかに大きなコストを意味します。

あなたも好きかもしれません