git-stash(1)

SYNOPSIS

git stash list [<log-options>]
git stash show [-u | --include-untracked | --only-untracked] [<diff-options>] [<stash>]
git stash drop [-q | --quiet] [<stash>]
git stash pop [--index] [-q | --quiet] [<stash>]
git stash apply [--index] [-q | --quiet] [<stash>]
git stash branch <branchname> [<stash>]
git stash [push [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
             [-u | --include-untracked] [-a | --all] [(-m | --message) <message>]
             [--pathspec-from-file=<file> [--pathspec-file-nul]]
             [--] [<pathspec>…]]
git stash save [-p | --patch] [-S | --staged] [-k | --[no-]keep-index] [-q | --quiet]
             [-u | --include-untracked] [-a | --all] [<message>]
git stash clear
git stash create [<message>]
git stash store [(-m | --message) <message>] [-q | --quiet] <commit>

DESCRIPTION

作業ディレクトリとインデックスの現在の状態を記録したいが、クリーンな作業ディレクトリに戻りたい場合は、git stash を使用します。このコマンドは、ローカルの変更を保存し、作業ディレクトリを元に戻して(revert)、HEAD コミットに一致させます。

このコマンドによってスタッシュされた変更は、 git stash list で一覧表示され、 git stash show で調査され、 git stash apply で復元されます(それは別のコミットの上にある可能性があります)。引数なしで git stash を呼び出すことは、 git stash push と同等です。スタッシュはデフォルトで WIP on 'branchname' ... としてリストされますが、作成するときにコマンドラインでより説明的なメッセージを与える事ができます。

作成した最新のスタッシュは refs/stash に保存されます。古いスタッシュはこのリファレンスのreflogにあり、通常のreflog構文を使用して名前を付けることができます(たとえば、 stash@{0} は最後に作成されたスタッシュで、 stash@{1} はその前のスタッシュです。 stash@{2.hours.ago} も可能です)。スタッシュは、スタッシュインデックスのみを指定することによって参照することもできます(たとえば、整数 n は stash@{n} と同等です)。

COMMANDS

あなたのローカルの変更を新しい「スタッシュエントリ」に保存し、それらをHEADに巻き戻します(作業ツリー内とインデックス内で)。 <message> の部分はオプションであり、スタッシュ状態と共に説明を提供します。

スナップショットをすばやく作成するために、「push」を省略できます。このモードでは、サブコマンドのスペルミスで不要なスタッシュエントリを作成するのを防ぐための非オプション引数は許可されていません。これに対する2つの例外は、 stash push -p のエイリアスとして機能する stash -p と、曖昧さ解消のために二重ハイフン -- の後ろで許可されるpathspec要素です。

このオプションは廃止され、 git stash push が採用されました。 pathspecをとることができないという点で「stash push」とは異なります。代わりに、オプション以外のすべての引数が連結されて、スタッシュメッセージが形成されます。

list [<log-options>]

現在持っているスタッシュエントリを一覧表示します。各「スタッシュエントリ」は、その名前(たとえば、 stash@{0} は最新のエントリ、 stash@{1} はその前のエントリ、など)と、エントリが作成されたときの現在のブランチの名前と、エントリが基づいていたコミットの簡単な説明と、ともに一覧表示されます。

stash@{0}: WIP on submit: 6ebd0e2... Update git-stash documentation
stash@{1}: On master: 9cc0589... Add git-stash

このコマンドは、 git log コマンドに適用可能なオプションを使用して、表示内容と方法を制御します。 git-log(1) を参照してください。

show [-u|--include-untracked|--only-untracked] [<diff-options>] [<stash>]

スタッシュエントリに記録された変更を、スタッシュされたコンテンツとスタッシュエントリが最初に作成されたときのコミットとの差分として表示します。デフォルトでは、コマンドはdiffstatを表示しますが、 git diff として認識される任意の形式を受け入れます(たとえば、パッチ形式で2番目に新しいエントリを表示するには git stash show -p stash@{1})。 <diff-option> が指定されていない場合、デフォルトの動作は stash.showStat および stash.showPatch 構成変数によって与えられます。 stash.showIncludeUntracked を使用して、 --include-untracked がデフォルトで有効になっているかどうかを設定することもできます。

pop [--index] [-q|--quiet] [<stash>]

スタッシュリストから単一のスタッシュ状態を削除し、現在の作業ツリー状態の上に適用します。つまり、 git stash push の逆の操作を実行します。作業ディレクトリはインデックスと一致している必要があります。

状態の適用は、競合で失敗する可能性があります。この場合、スタッシュリストからは削除されません。競合を手動で解決し、後で手動で git stash drop を呼び出す必要があります。

apply [--index] [-q|--quiet] [<stash>]

pop と同様ですが、スタッシュリストから状態を削除しないでください。 pop とは異なり、<stash> は、stash push または stash create によって作成されたコミットのように見える任意のコミットです。

branch <branchname> [<stash>]

<stash> が元々作成された時のコミットから <branchname> という名前の新しいブランチを作成してチェックアウトし、 <stash> に記録された変更を新しい作業ツリーとインデックスに適用します。それが成功し、 <stash> が stash@{<revision>} 形式の参照である場合、 <stash> を削除します。

これは、あなたが git stash push を実行したブランチがとても変更されていて、git stash apply が競合のために失敗した場合に便利です。スタッシュエントリは、 git stash が実行されたときにHEADであったコミットの上に適用(apply)されるため、競合することなく元のスタッシュされた状態を復元します。

clear

すべてのスタッシュエントリを削除します。これらのエントリは刈り込みの対象となり、回復できない可能性があることに注意してください(可能な戦略については、下記「Examples」を参照してください)。

drop [-q|--quiet] [<stash>]

スタッシュエントリリストからスタッシュエントリを1つ削除します。

create

ref名前空間のどこにも保存せずに、スタッシュエントリ(通常のコミットオブジェクト)を作成し、そのオブジェクト名を返します。これは、スクリプトで役立つことを目的としています。おそらくあなたがこのコマンドを使用することはありません。上記「push」を参照してください。

store

git stash create を介して作成された特定のスタッシュ(これは宙ぶらりんマージコミット(dangling merge commit)です)をスタッシュrefに格納し、スタッシュreflogを更新します。これは、スクリプトで役立つことを目的としています。おそらく、あなたはこのコマンドを使用することはありません。上記「push」を参照してください。

OPTIONS

-a
--all: このオプションは、 push および save コマンドでのみ有効です。

無視され追跡されていないすべてのファイルもスタッシュしてから、 git clean でクリーンアップします。
-u
--include-untracked
--no-include-untracked: push および save コマンドと一緒に使用すると、追跡されていないすべてのファイルもスタッシュし、 git clean でクリーンアップします。

show コマンドと一緒に使用すると、diffの一部としてスタッシュエントリの追跡されていないファイルを表示します。
--only-untracked: このオプションは、 show コマンドでのみ有効です。

diffの一部として、スタッシュエントリ内の、追跡されていないファイル(untracked files)のみを表示します。
--index: このオプションは、 pop および apply コマンドにのみ有効です。

作業ツリーの変更だけでなく、インデックスの変更も復元しようと試みます。ただし、競合がある場合(競合がインデックスに保存されているため、元の変更を適用できなくなる)、これは失敗する可能性があります。
-k
--keep-index
--no-keep-index: このオプションは、 push および save コマンドでのみ有効です。

インデックスにすでに追加されているすべての変更はそのまま残ります。
-p
--patch: このオプションは、 push および save コマンドでのみ有効です。

HEADと作業ツリー間のdiffから、スタッシュするハンクを対話的に選択します。スタッシュエントリは、リポジトリのインデックス状態と同じになるように構築され、そのワークツリーには、対話的に選択した変更点のみが含まれます。そして、選択した変更はワークツリーから巻き戻されます。 --patch モードの操作方法については、 git-add(1) の「Interactive Mode」セクションを参照してください。

--patch オプションは --keep-index の指定を含んでいます。あなたは --no-keep-index を使用してこれを上書きできます。
-S
--staged: このオプションは、 push および save コマンドでのみ有効です。

現在ステージングされている変更のみをスタッシュします。これは、状態が現在のブランチではなくスタッシュにコミットされることを除いて、基本的な git commit に似ています。

--patch オプションはこれよりも優先されます。
--pathspec-from-file=<file>: このオプションは、 push コマンドにのみ有効です。

pathspecは、コマンドライン引数の代わりに <file> で渡されます。 <file> が正確に - の場合、標準入力が使用されます。 pathspec要素はLFまたはCR/LFで区切られます。 pathspec要素は、構成変数 core.quotePath にて説明されているようにクォートできます(git-config(1) 参照)。 --pathspec-file-nul およびグローバルの --literal-pathspecs も参照してください。
--pathspec-file-nul: このオプションは、 push コマンドにのみ有効です。

このオプションは --pathspec-from-file でのみ意味があります。 pathspec要素はNUL文字で区切られ、他のすべての文字は文字通りに解釈されます(改行と引用符を含む)。
-q
--quiet: このオプションは、 apply, drop, pop, push, save, store コマンドにのみ有効です。

静かにして、フィードバックメッセージを抑制します。
--: このオプションは、 push コマンドにのみ有効です。

曖昧さ解消の目的のために pathspec をオプションから分離します。
<pathspec>…: このオプションは、 push コマンドにのみ有効です。

新しいスタッシュエントリは、pathspecに一致するファイルについてのみ変更された状態を記録します。次に、インデックスエントリと作業ツリーファイルは、これらのファイルについてのみHEADの状態に巻き戻されされ、pathspecに一致しないファイルはそのまま残ります。

詳細については、 gitglossary(7) の「pathspec」エントリを参照してください。
<stash>: このオプションは、 apply, branch, drop, pop, show コマンドにのみ有効です。

stash@{<revision>} 形式の参照。 <stash> が指定されていない場合、最新のスタッシュ(stash@{0})を想定します。

DISCUSSION

スタッシュエントリーは、作業ディレクトリの状態を記録するツリーを持つコミットとして表現され、その最初の親はエントリーが作成された HEAD でのコミットとなります。 2番目の親のツリーは、エントリーが作成されたときのインデックスの状態を記録しており、HEAD コミットの子として作られます。祖先のグラフは以下のようになります:

       .----W
      /    /
-----H----I

ここで、 H は HEAD コミット、 I はインデックスの状態を記録するコミット、 W は作業ツリーの状態を記録するコミットです。

EXAMPLES

Pulling into a dirty tree

あなたが何かしている最中、あなたがしていることにおそらく関連しているかもしれないアップストリームの変更があったことを知りました。あなたのローカルの変更がアップストリームの変更と競合しない場合は、単純に `git pull `で先に進むことができます。

しかしながら、あなたのローカルの変更がアップストリームの変更と競合し、 git pull が変更の上書きを拒否する場合があります。このような場合、以下のように、変更をスタッシュし、プルしてから、スタッシュ解除できます:

$ git pull
 ...
file foobar not up to date, cannot merge.
$ git stash
$ git pull
$ git stash pop

Interrupted workflow

あなたが何かやってる真っ最中に、上司がやって来て、あなたにすぐに何かを直すように要求します。従来は、一時的なブランチにコミットして変更を保存し、元のブランチに戻って以下のように緊急修正を行っていました:

# ... hack hack hack ...
$ git switch -c my_wip
$ git commit -a -m "WIP"
$ git switch master
$ edit emergency fix
$ git commit -a -m "Fix in a hurry"
$ git switch my_wip
$ git reset --soft HEAD^
# ... continue hacking ...

git stash を使用することで上記を以下のように簡略化できます:

# ... hack hack hack ...
$ git stash
$ edit emergency fix
$ git commit -a -m "Fix in a hurry"
$ git stash pop
# ... continue hacking ...

Testing partial commits

ワークツリーの変更から2つ以上のコミットを行い、コミットする前に各変更をテストする場合は、 git stash push --keep-index を使用できます:

# ... hack hack hack ...
$ git add --patch foo            # add just first part to the index
$ git stash push --keep-index    # save all other changes to the stash
$ edit/build/test first part
$ git commit -m 'First part'     # commit fully tested change
$ git stash pop                  # prepare to work on all other changes
# ... repeat above five steps until one commit remains ...
$ edit/build/test remaining parts
$ git commit foo -m 'Remaining parts'

将来の使用のために無関係な変更を保存

大規模な変更の最中に、修正を忘れたくない無関係な問題を見つけた場合、変更を行い、それらをステージングし、 git stash push --staged を使用して将来の使用のためにスタッシュしておくことができます。これは、ステージングされた変更をコミットするのと似ていますが、コミットのみが現在のブランチではなくスタッシュに配置されます。

# ... hack hack hack ...
$ git add --patch foo           # add unrelated changes to the index
$ git stash push --staged       # save these changes to the stash
# ... hack hack hack, finish current changes ...
$ git commit -m 'Massive'       # commit fully tested changes
$ git switch fixup-branch       # switch to another branch
$ git stash pop                 # to finish work on the saved changes

誤ってクリアまたはドロップされたスタッシュエントリの回復

誤ってスタッシュエントリをドロップまたはクリアした場合、通常の安全メカニズムでは回復できません。ただし、以下の呪文を試して、リポジトリに残っているが到達できなくなったスタッシュエントリのリストを取得できます:

git fsck --unreachable |
grep commit | cut -d\  -f3 |
xargs git log --merges --no-walk --grep=WIP

CONFIGURATION

このセクションの以下のすべては、 git-config(1) ドキュメントの抜粋です。内容は git-config(1) ドキュメントにあるものと同一です:

stash.showIncludeUntracked: これがtrueに設定されている場合、 git stash show コマンドはstashエントリの追跡されていないファイルを表示します。デフォルトはfalseです。 git-stash(1) の showコマンドの説明を参照してください。
stash.showPatch: これがtrueに設定されている場合、オプションのない git stash show コマンドは、パッチ形式でstashエントリを表示します。デフォルトはfalseです。 git-stash(1)の showコマンドの説明を参照してください。
stash.showStat: これがtrueに設定されている場合、オプションのない git stash show コマンドは、stashエントリのdiffstatを表示します。デフォルトはtrueです。 git-stash(1) の showコマンドの説明を参照してください。

GIT

Part of the git(1) suite

git-stash(1) Manual Page

NAME