Git stash: 変更を保存し、ブランチを切り替え、作業内容を復元します

Git stash はコミットされていない変更を保存するため、別の作業を行ってから、それらの変更を元に戻すことができます。 git stash push -m "WIP: checkout form" で始めます。保存されたエントリを保持したい場合は git stash apply を使用して復元し、復元が成功した後にエントリを削除したい場合は git stash pop を使用します。新しい追跡されていないファイルも作品に属する場合は、-u を追加します。

このガイドでは、例としてチェックアウト フォームの中断を使用します。フォームを一時停止し、別のブランチで運用上のバグを修正してから、フォームに戻ります。視覚的なチュートリアルでは、macOS、Windows、および Linux 用に作成したクライアントである GitTree を使用します。スタッシュ管理は無料プランに含まれています。現在の公式ビルドにはサインインが必要です。

スタッシュ、コミット、またはワークツリーをいつ使用するか

より長い並列タスクの場合は、ワークツリー ガイド を使用してください。隠し場所は便利な一時保管場所ですが、貴重な作業の唯一のバックアップであるべきではありません。 stash@{0} は最新のエントリを意味し、リストが変更されると番号も変わるため、タスクの後にエントリに名前を付けます。

変更を保存してブランチを切り替える: 完全な例

最初に git status を検査します。デフォルトのスタッシュには、段階的編集など、追跡されたファイルへの変更が含まれていますが、追跡されていないファイルや無視されたファイルはそのまま残されます。この例では、フォームに新しく作成されたファイルが含まれているため、-u を使用します。これらのコマンドは、feature/checkout と hotfix/payment がすでに存在していることを前提としています。独自のブランチ名に置き換えてください。

git status
git stash push -u -m "WIP: checkout form"
git stash list
git status
git switch hotfix/payment

戻る前にホットフィックスを終了し、テストしてコミットします。適用する前に、スタッシュ リストとその差分を確認してください。その間に、別のタスクが新しいエントリを作成した可能性があります。 "stash@{0}" などのセレクターを引用符で囲むと、シェルがその特殊文字を解釈できなくなります。

git switch feature/checkout
git stash list
git stash show -p --include-untracked "stash@{0}"
git stash apply "stash@{0}"
git status

Git stash apply と Pop: どちらを選択する必要がありますか?

重要な未完了の変更については、最初に適用し、確認してテストし、復元作業をコミットした後で保存したエントリを削除します。 2 回適用すると、競合が発生したり、変更が繰り返されたりする可能性があります。再試行する前に作業ファイルを検査してください。 apply も Pop もサーバーに何もプッシュしません。

追跡されていないファイル、特定のファイル、または段階的な変更を隠します

git stash push -u -m "WIP: include new files"
git stash push -m "WIP: checkout only" -- src/checkout.ts
git stash push --staged -m "WIP: staged changes only"
git stash push --keep-index -m "WIP: keep staged work ready"

これらは 代替コマンドであり、一緒に実行するシーケンスではありません。 -- の後のパスは、スタッシュをそのパスに制限します。 --staged は段階的な変更のみを保存します。 --keep-index では段階的な変更がそのまま残されるため、他の編集を棚上げしながら変更をテストまたはコミットできます。彼らはさまざまな問題を解決します。古い Git インストールでは --staged がサポートされていない可能性があります。 git --version とインストールされているバージョンのヘルプを確認してください。

独自のリポジトリで次の手順を実行したいですか? GitTree をダウンロード してサインインし、リポジトリ フォルダーを開きます。既存のスタッシュは通常の Git スタッシュのままで、ターミナルからも表示されます。

git stash ポップの競合を解決する方法

宛先ブランチが同じ行を変更すると、スタッシュが競合する可能性があります。失敗したポップは隠し場所を保持しますが、一部の変更がすでに適用されている可能性があります。繰り返しポップしないでください。 git status を実行し、マージされていない各ファイルを解決し、目的の解決のみをステージングします。 マージ競合ガイド では、マーカーと 3 方向エディターについて説明しています。

git status
git diff --name-only --diff-filter=U
# Edit and test each conflicted file, then stage its resolution:
git add -- src/checkout.ts
git diff --cached
git status

git stash --continue または git stash --abort はありません。ファイルが解決されたら、通常どおりレビューしてコミットします。試行を中止する場合は、適用前に存在していた作業を保存し、変更されたパスをすべて検査してから、何も破棄しないようにしてください。一括ハード リセットを行うと、無関係な編集内容が消去される可能性があります。宛先が分岐しすぎた場合、git stash branch rescue/checkout "stash@{0}" は元のベースの新しいブランチに復元します。操作が成功すると、その隠しエントリが削除されます。

結果を確認した後にのみスタッシュを削除します

git stash drop "stash@{0}" の前にもう一度 git stash list を使用します。位置が変更されている可能性があります。 git stash clear はリスト全体を削除します。プレーン Git でドロップされたスタッシュの回復は不確実であり、そのオブジェクトがまだ存在するかどうかによって異なります。後で見つけることに依存しないでください。 GitTree では、削除されたエントリが [元に戻す] で復元できるように、削除されたエントリが回復スナップショットに保持されます。アプリ固有の回復では、端末の削除が回復可能なアクションとして保証されるわけではありません。より広範な回復オプションについては、Git の間違いを元に戻す を参照してください。