git stash とは、作業木と index の未 commit の変更を一時的に退避し、作業木を HEAD の状態へ戻す git の命令です。
- git stash の push・pop・apply・drop・list・show が何をするか、pop が衝突したとき stash はどうなるか
- git pull --rebase --autostash が裏で stash を作って当て直す仕組みと、当て直しで衝突する所
- 当社が複数の席で 1 つの作業木を使い、autostash が他の席の変更を巻き上げた記録と、stash から戻した手順
当社は、コードや文書の変更を AIエージェント の席に書かせています。席が自分で git を撃つので、人が 1 人で使うときには気にしない --autostash の「他人の変更まで退避する」性質が、実際の事故になりました。この頁は git の公式の文書の定義と、その記録を並べたものです。
git stash の命令と、それぞれ何をするか
引数なしの git stash は git stash push と同じです。退避した物は stash の一覧に積まれ、stash@{0} が最も新しい物、stash@{1} がその 1 つ前です（git-stash の文書）。
| 命令 | 何をするか（公式の文書） | stash の一覧に残るか |
|---|---|---|
git stash push（git stash） | 手元の変更を新しい stash に保存し、作業木と index を HEAD へ戻す | 増える |
git stash pop | stash を 1 つ一覧から外し、今の作業木の上に当てる（push の逆） | 外れる。ただし衝突したら残る |
git stash apply | pop と同じく当てるが、一覧からは外さない | 残る |
git stash drop | stash を 1 つ一覧から消す | 消える |
git stash list | 今ある stash を、名前・作った時の branch・元の commit の説明つきで並べる | 変えない |
git stash show | stash の中身を、作った時の commit との差として出す（既定は diffstat） | 変えない |
出典: git-scm.com「git-stash」https://git-scm.com/docs/git-stash （2026-11-05 に確認）。
git stash を戻す：pop と apply、衝突したときは stash が残る
退避した変更を戻すのは git stash pop か git stash apply です。違いは、当てた後に一覧から外すかどうかだけです。他人の変更が混ざっているかもしれない stash は、apply で当てて中身を確かめてから drop する方が、取り返しがつきます。
公式の文書では、当てるときに衝突すると、pop でも stash は一覧から外されず残り、終了コードは 1 です。衝突を手で解いてから、自分で git stash drop を撃ちます。つまり「git stash pop で衝突して変更が消えた」ように見えても、stash の一覧にはまだ在ります。まず git stash list と git stash show で探します。
stash の正体は commit です。作業木の状態を記録した commit で、1 つ目の親が作った時の HEAD、2 つ目の親が作った時の index の状態です（git-stash の文書）。下の復旧の手順は、この形を使って「HEAD と stash の差」に在るファイルだけを取り出しています。
git pull --rebase --autostash は、裏で stash を作って当て直す
--autostash は、操作の前に一時の stash を作り、操作の後に当てる印です。これで作業木が汚れたままでも pull や rebase を撃てます。同時に、公式の文書はどちらも「操作が成功した後の最後の当て直しで、厄介な衝突が起き得る」と注意を書いています。
| 書き方 | 公式の文書の定義 |
|---|---|
git pull --autostash | 操作の前に一時の stash を作って ref MERGE_AUTOSTASH に記録し、操作の後に当てる。成功した merge の後の当て直しで衝突し得る |
git rebase --autostash | 操作の前に一時の stash を作り、操作の後に当てる。成功した rebase の後の当て直しで衝突し得る |
rebase.autoStash（設定） | true にすると rebase で毎回 autostash する。既定は false。--no-autostash で打ち消せる |
出典: git-scm.com「git-pull」https://git-scm.com/docs/git-pull ・「git-rebase」https://git-scm.com/docs/git-rebase （どちらも 2026-11-05 に確認）。
見落としやすいのは、autostash が退避するのは「作業木の未 commit の変更すべて」だという点です。誰が書いた変更かは見ません。1 人の作業木なら全部自分の物ですが、複数の席が同じ作業木を書いていると、他の席が書きかけの変更も一緒に stash に入り、当て直しの衝突もその席の物で起きます。
共有の作業木で、autostash が他の席の変更を巻き上げた記録
当社では、同じ形の事故が 3 回起きました。どれも、ある席が共有の作業木で git pull --rebase --autostash を撃ち、他の席の未 commit の変更が autostash に入り、当て直しで 1 本が衝突した形です（社の実測 2026-09-18・2026-10-14）。
| 日付 | 巻き込まれた他の席の変更 | 当て直しで起きた事 | どう収めたか |
|---|---|---|---|
| 2026-09-18 | 32 本 | 1 本（CLAUDE.md）で pop が衝突し、32 本が作業木から消えた（stash には残った） | stash から 32 本を作業木へ戻した（次の節） |
| 2026-09-18（別件） | 25 ファイル | 1 本が衝突（Updated upstream と Stashed changes の印） | 持ち主の席が自分で解いて、実害なし |
| 2026-10-14 | 26 ファイル | 他の箱の紙で DU 衝突。26 ファイルが stash@{0} に巻き上がり、staged に化けた | pre-commit の門が止めて気づいた。stash@{0} は drop しなかった |
出典: 社の実測 2026-09-18・2026-10-14。
2026-10-14 の stash@{0} を drop しなかったのは、他の席の物を含んでいたからです。中を見ると、うち 2 本は今の作業木の中身と違っていました（社の実測 2026-10-14）。stash を消すと、その 2 本の版はどこにも残りません。自分が作ったのではない stash は、持ち主が確かめるまで消さない、と決めています。
git stash pop conflict で作業木から消えた変更を、stash から戻した手順
2026-09-18 の 1 件目は、pop が 1 本で衝突し、32 本が作業木から消えた形でした。公式の文書の通り stash は一覧に残っていたので、そこから戻しました（社の実測 2026-09-18）。
| 順 | 撃った命令 | 何のためか |
|---|---|---|
| 1 | git diff --name-only -z stash^ stash | xargs -0 git checkout stash -- | stash を作った時の HEAD（stash^）と stash の差に在るファイルだけを、stash の版で作業木へ戻す。32 本が戻った |
| 2 | git reset | git checkout stash -- … は index にも載せるので、未 commit・未 stage の元の形に戻す |
| 3 | （stash は drop しない） | 戻し損ねがあった時の保険として残した |
出典: 社の実測 2026-09-18。-z と xargs -0 は、名前に空白や日本語を含むファイルでも切れないようにするためです。
生成物が UU になったら HEAD の側で解く
毎回作り直す生成物のファイルが、autostash の当て直しで UU（両側が変えた衝突）になる型が、2026-10-06・2026-10-07・2026-10-25 に繰り返し起きました（社の実測 2026-10-06・2026-10-07・2026-10-25）。
生成物は手で混ぜる意味が無いので、git checkout HEAD -- <道> で HEAD の側に揃えて解き、要るなら作り直します。一方、同じ stash に入っていた他の席の変更は stash に残して消しませんでした（社の実測 2026-10-06・2026-10-07・2026-10-25）。生成物を片付けるついでに stash ごと drop すると、他人の変更まで消えます。
pull が abort したのに、成功として記録された
2026-09-20、予約で動く席が共有の clone で git pull --rebase --autostash を撃ち、他の席の未 commit の変更が理由で pull が abort しました（exit=128）。ところがその席は abort に気づかず「スキップ」と書いて自分の仕事を閉じ、記録には成功として残りました（社の実測 2026-09-20）。
autostash を付けても、pull が必ず通るわけではありません。止まった時に終了コードを見ずに先へ進む書き方だと、失敗が成功として残ります。席に git を撃たせるなら、終了コードが 0 でない時は「スキップ」でなく「止まった」と返させます。
git checkout -- で戻したつもりの編集が、2 時間後に stash に入った
2026-10-15、ある席が git checkout -- <file> で編集を戻したつもりでした。しかしその変更は既に add されていて、checkout は index の staged の版から作業木を戻しただけで、編集は index に残っていました。2 時間後、別の席の pull --rebase --autostash がそれを stash に巻き上げました（社の実測 2026-10-15）。
その stash は、stash@{n} の番号でなく SHA で引いて中身を確かめてから drop しました（社の実測 2026-10-15）。番号は新しい stash が積まれるたびにずれるので、複数の席が stash を作り得る場では、確かめた物と消す物が同じだと SHA で揃えます。
戻すときは index ごと戻す git restore --staged --worktree <file> を使います（社の実測 2026-10-15）。add の取り消しと、commit にファイルを名指しする理由は git add の取り消しの頁にまとめています。
当社の決まり：共有の作業木では --autostash も stash も使わない
上の記録から、当社は次のように決めています（社の実測 2026-09-18 の決め事と、社の規矩）。
| 場面 | やる事 | やらない事 |
|---|---|---|
| pull の前 | git status --short が空かを確かめる。空でなければ pull しない | 汚れた作業木で --autostash を付けて押し通す |
| main の最新を読むだけ | git fetch して git show origin/main:<道> で読む | 読むためだけに pull する |
| pull や rebase が止まった | fetch と show で読み、他の席の変更には触れない | stash して片付ける・stash を drop する |
| 席を並べる | 席ごとに worktree を分ける（本筋） | 複数の席で 1 つの作業木と index を共有する |
出典: 社の実測 2026-09-18（pull の前の確かめと fetch・show）と、当社の規矩。
席ごとに作業木を分ける形は Claude Code を並列で動かす頁に、rebase の途中と共有の clone の index で起きる事は git push --force-with-lease の頁に書いています。
よくある質問
git stash pop で衝突したら、stash は消える？
消えません。公式の文書では、当てる時に衝突すると stash は一覧に残り、終了コードは 1 です。衝突を手で解いてから、自分で git stash drop を撃ちます。
git stash で退避した変更が消えた。どこを探す？
まず git stash list で一覧を見て、git stash show で中身を確かめます。pop や autostash の当て直しが衝突した場合、変更は作業木から消えても stash には残っています。当社は 2026-09-18 に、作業木から消えた 32 本を stash から戻しました（社の実測 2026-09-18）。
git pull --rebase --autostash の autostash とは？
pull や rebase の前に一時の stash を作り、終わった後に当て直す印です（git-pull・git-rebase の文書）。作業木が汚れていても撃てますが、当て直しで衝突し得ると公式の文書が注意しています。退避は作業木の未 commit の変更すべてが対象で、誰の変更かは区別しません。
git stash の pop と apply はどう使い分ける？
pop は当てた後に stash を一覧から外し、apply は残します（git-stash の文書）。中身に自信が無い stash や、他人の変更が混ざっているかもしれない stash は、apply で当てて確かめてから drop する方が安全です。
複数の AI エージェントで同じリポジトリを触る時、stash は使ってよい？
当社は、共有の作業木では --autostash も stash も使わない決まりにしています。他の席の書きかけの変更まで退避され、当て直しの衝突で作業木から消えた記録があるためです（社の実測 2026-09-18・2026-10-14）。席ごとに worktree を分けるのが本筋です。
出典
- git-scm.com「git-stash」https://git-scm.com/docs/git-stash （2026-11-05 に確認）
- git-scm.com「git-pull」https://git-scm.com/docs/git-pull （2026-11-05 に確認）
- git-scm.com「git-rebase」https://git-scm.com/docs/git-rebase （2026-11-05 に確認）
- 社の実測 2026-09-18・2026-09-20・2026-10-06・2026-10-07・2026-10-14・2026-10-15・2026-10-25
ブルーランプ 記事の編集部／更新日 2026-11-05