【Git】ローカル動作確認の一時コミット＆巻き戻し方法｜stash・scratch branch・worktreeの使い分け完全ガイド

【Git】ローカルでだけ動作確認したいときの一時的なコミット＆巻き戻し方法 Git
2025.05.26

「ビルドを通すために一時的にハードコードしたい」「バグ切り分けのためprint文を埋め込んで試したい」「本線のコミットに混ぜたくない検証コードがある」——開発中は、本番コミットしたくない変更をローカルだけで試したい場面がよくあります。

この記事ではGitでローカル動作確認をするための5つの手法（stash／一時コミット＋巻き戻し／scratch branch／worktree／-nパッチ適用）を比較し、シーン別の使い分けを解説します。「temp commit→reset」で済ませがちなシーンでも、目的に応じた手法を選ぶと事故（push漏れ・巻き戻し失敗・共有ブランチへの混入）を減らせます。

この記事で学べること

  • 検証用ローカル作業の5手法とそれぞれの強み／弱み
  • git stashで素早く退避し、確認後に戻す流れ
  • 一時コミット＋git reset --soft/--mixed/--hardの使い分け
  • scratch branchで検証空間を物理的に分離する方法
  • git worktreeで並行作業ディレクトリを増やす方法
  • 「誤ってpushしてしまった」を防ぐ運用ルール
  • 検証が終わったあとのクリーンアップ手順
スポンサーリンク

5つの手法を比較する

どの手法も「ローカル限定の一時変更を扱う」という目的は同じですが、捨てやすさ・復元しやすさ・誤pushのリスクが違います。状況で使い分けるのがベストです。

手法 向いている場面 誤pushリスク
① git stash 退避して復元、短時間の切り替え 低（indexに上がらない）
② 一時コミット＋reset ビルドが必要／stashが合わない変更 中（git pushで出てしまう）
③ scratch branch 検証コードを丸ごと分離 低（ブランチ分離）
④ git worktree 並行して別ディレクトリで検証 低（完全分離）
⑤ git apply --index 差分パッチを当てる／戻す 低（パッチ管理）

ポイント：迷ったらstashかscratch branchが安全です。一時コミット＋resetも便利ですが、勢いでgit pushして「temp commit」がリモートに出てしまう事故が起きやすいので、共有ブランチ上では避けるのが賢明。目的別に使い分けを学んでいきましょう。

手法①：git stashで退避する

git stashはまさに「一時的に変更を退避する」ための機能。変更をコミットせずに仮置きしておき、動作確認後に戻すか捨てるかを選べます。検証コードを本線に混ぜたくないシーンでは第一選択肢です。

stashで退避→復元
# 退避（未追跡ファイルも含める -u）
git stash push -u -m "wip: 一時検証コード"

# 必要な変更を適用して動作確認
# 例: デバッグ用コードを書いてビルド確認
npm run build

# 検証が終わったら退避した変更を戻す
git stash pop
# → 作業ツリーに復元、stash entryは自動削除

# 戻すだけ（entryは残す）なら apply
git stash apply

# 不要なら削除
git stash drop

複数のstashを管理する

stash一覧と個別操作
# 一覧表示
git stash list
# stash@{0}: On main: wip: 一時検証コード
# stash@{1}: On feature/xxx: wip: 他の検証

# 特定stashの差分を確認
git stash show -p stash@{0}

# 特定stashだけ戻す
git stash pop stash@{1}

# 全stash削除
git stash clear

stashの長所・短所

  • 長所：コミット履歴を汚さない／誤pushの心配ほぼゼロ
  • 長所：複数の退避を同時に持てる
  • 短所：ビルド対象がstash対象だと、退避するとビルドできない
  • 短所：stashの管理が雑になると迷子のstashが増える

stashを失ってしまった時の復元はstashした内容を失ってしまったときの復元方法を参照してください。

手法②：一時コミット＋resetで巻き戻す

「変更込みでビルドして動かしたい」場合は一時コミットが必要です。作業ツリーにあるだけではビルド成果物に反映されないツール（packaged buildなど）でよく使われるパターン。動作確認後にresetで巻き戻すのがセオリーです。

一時コミット→reset の流れ
# 変更を全部ステージ
git add .

# 一時コミット（prefix で目立たせる）
git commit -m "WIP: 検証用の一時コミット（後で戻す）"

# ビルド・動作確認
npm run build
# 開発サーバー起動など
npm run start

# 確認が終わったら巻き戻し
# ステージに戻す（変更は残す）
git reset --soft HEAD~1

# ステージングも解除（作業ツリーのみ）
git reset --mixed HEAD~1   # デフォルト

# 完全に捨てる（変更も破棄）
git reset --hard HEAD~1
オプション コミット取消 ステージ 作業ツリー
--soft ○ 保持 保持
--mixed ○ 解除 保持
--hard ○ 解除 破棄

警告：この方法には最大の落とし穴があります——うっかりgit pushするとリモートに「WIP: 検証用」コミットが出てしまう。特にpush.autoSetupRemoteや自動pushツールを使っていると事故になりやすい。共有ブランチでは使わない、またはscratch branchで分離してから実行しましょう。

reset全般の詳細は特定のコミットまで戻す方法、コミット取り消しの概念はコミットの取り消し方を参照。

手法③：scratch branchで検証空間を分離

一時コミットのリスクを抑える最も確実な方法は、使い捨て前提のブランチを切って、そこで自由に実験することです。本線ブランチを汚さず、検証終了後はブランチごと削除できます。

scratch branchの運用
# 実験用ブランチを切る
git switch -c scratch/debug-auth

# 自由に変更・コミット
git add .
git commit -m "wip: 認証デバッグ用"
npm run build && npm run test

# 検証完了、何か採用するものがあれば cherry-pick
git switch main
git cherry-pick <SHA>   # 必要な部分だけ持ち込む

# 不要になったscratchブランチを削除
git branch -D scratch/debug-auth

scratch branch 命名ルール

  • scratch/やwip/プレフィックスで捨てる前提を明示
  • 個人名やタスク名を含めて迷子ブランチにしない（scratch/tom-debug-auth等）
  • チームリポではこれらを.github/CODEOWNERSやブランチ命名規約に記載
  • 長期放置しないルールも決めておく（不要ブランチの定期整理）

scratch branchのベースは派生元を選べるのも強みです。タグや過去コミットから実験を始めたい場合は過去のコミットから新しいブランチを作り作業をやり直す方法を参照してください。

手法④：git worktreeで並行ディレクトリを作る

「今の作業をcommit／stashせずに、別のブランチを別ディレクトリで並行確認したい」時の強力な手段がgit worktreeです。1リポジトリで複数の作業ディレクトリを持てます。

worktreeの使い方
# 新しいworktreeを別ディレクトリに作成
git worktree add ../repo-experiment
# または指定ブランチで
git worktree add ../repo-hotfix -b hotfix/urgent

# 既存ブランチで別worktreeを開く
git worktree add ../repo-review review/pr-42

# worktree一覧
git worktree list

# worktree削除（変更がある場合は削除前にcommit or捨てる）
git worktree remove ../repo-experiment

# ディレクトリごと消えてしまった場合のクリーンアップ
git worktree prune

worktreeの強み

  • メインの作業を止めずに並行別検証
  • ビルド生成物・node_modules等も別ディレクトリで独立
  • 検証終了後はディレクトリごと消せば完全に片付く
  • エディタ（VS Code等）で複数ウィンドウ同時に開ける
  • 同じブランチは2つのworktreeに同時に存在できない

注意：worktree先は.gitディレクトリを共有するので、メインリポの.gitを消すと全worktreeが壊れます。メンテナンス時はgit worktree listでwork treeの存在を確認してください。

手法⑤：パッチファイルで当てる／戻す

検証コードが固定で、何度も当てたり戻したりしたいときはパッチ化が便利です。Gitから離れてファイルとして保存でき、他人にも配布可能です。

パッチの作成と適用
# 作業ツリーの差分をパッチファイル化
git diff > /tmp/debug.patch

# 特定ファイルだけ
git diff src/debug.py > /tmp/debug.patch

# 別マシンで適用
git apply /tmp/debug.patch

# indexまで含めて当てる
git apply --index /tmp/debug.patch

# 戻す（-Rで逆適用）
git apply -R /tmp/debug.patch

# チェックだけ（実際には当てない）
git apply --check /tmp/debug.patch

ポイント：パッチはGit外の存在なので、ブランチ切り替え・リモートpush・同僚との共有に影響しません。ただしコンフリクト解消にはGitより手動対応が必要なので、長く使うパッチは徐々にscratch branch＋cherry-pick運用に移行するのが無難です。

どの手法を選ぶか：シーン別の指針

こんな時 おすすめ手法
数分〜1時間の検証、すぐ戻す ① stash
コミットしないとビルドできない（バージョン情報埋め込み等） ② 一時コミット＋reset（scratch branch上で）
複数コミットを試して比較したい ③ scratch branch
今の作業を中断せず別ブランチも試したい ④ worktree
固定のデバッグパッチを何度も当て外しする ⑤ パッチファイル

初心者はこの順序で覚える

  • まずstash（push -u＋pop）を習慣化
  • 次にscratch branch（switch -c scratch/xxx）で分離
  • 慣れたらworktreeで並行作業
  • 一時コミット＋resetは誤push事故が多いので慎重に

実践シナリオ

シナリオ① console.logを埋めてビルド確認、あとで戻す

stashで素早く
# console.log を埋める
vim src/auth.ts

# そのままビルドで動作確認
npm run build
npm run test

# 問題なく動いたら console.log を消してstash
git stash push -u -m "debug console.log"

# 本来の修正作業に集中
# 戻したいときは
git stash pop

シナリオ② ビルドに含めた形で動作確認したい

scratch branch＋一時コミット
# 検証用ブランチに切替
git switch -c scratch/ver-check main

# 検証コードをコミット
git add .
git commit -m "WIP: バージョン文字列仮埋込"

# ビルド
npm run build
npm run test

# 確認後、scratchは不要
git switch main
git branch -D scratch/ver-check

シナリオ③ 現在の作業中断せずに別ブランチを検証

worktreeで並行
# 現在mainで作業中、作業ツリーに未コミット変更あり
# 新worktreeを別ディレクトリに作成
git worktree add ../proj-review review/pr-42

# 別ディレクトリで
cd ../proj-review
npm install
npm run test

# 元の作業に戻る
cd ../original-proj
# 作業継続（中断なし）

# worktree不要になったら削除
git worktree remove ../proj-review

シナリオ④ 誤って一時コミットをpushしてしまった

pushを取り消す
# 個人ブランチなら
git reset --hard HEAD~1
git push --force-with-lease

# 共有ブランチならrevert
git revert <temp_commit_SHA>
git push

push取り消しはpushを取り消す方法で詳しく解説しています。

誤pushを防ぐ運用ルール

検証作業を安全に運用するコツ

  • 検証用コミットは必ずWIP:／temp:等のprefixを付ける
  • 検証作業はscratch branchで行う（main/feature上の一時コミットを避ける）
  • pre-push hookでWIP:を含むコミットを検出して警告
  • Branch protection rulesで保護ブランチへの直接pushを禁止
  • git statusとgit log --oneline -3をpush前の確認習慣に
pre-push hookの例
# .git/hooks/pre-push
#!/bin/sh
remote="$1"
while read local_ref local_sha remote_ref remote_sha; do
  # WIP/tempコミットが含まれていないかチェック
  if git log --format=%s "$remote_sha..$local_sha" 2>/dev/null | \
     grep -E "^(WIP|wip|temp|TEMP):"; then
    echo "Error: WIP/tempコミットをpushしようとしています"
    exit 1
  fi
done
exit 0

実行権限付与：chmod +x .git/hooks/pre-push。チーム全員に配布するならcore.hooksPathかhusky等のツールを利用しましょう。

やってはいけない落とし穴

一時コミットのまま共有ブランチで push してしまう

一時コミット＋resetの最大のリスクが「git pushを習慣で打ってしまう」こと。チームリポに「WIP: 動作確認」「temp: debug」コミットが残ると、レビュー・リリースノート・bisectで混乱の元になります。scratch branchで作業するか、stashを使って誤pushのリスクを物理的に下げてください。

stashを大量に作って迷子にする

stashは便利で気軽に使えますが、10個、20個と溜めると管理できなくなります。「どのstashが何のために作ったか分からない」という状況になったら、git stash listで一覧を確認し、不要なものをgit stash drop／clearで整理しましょう。復旧はstashした内容を失ってしまったときの復元方法参照。

reset –hardで重要な未コミット変更を消す

一時コミットを--hardで巻き戻す際、同じ作業ツリーに別の未コミット変更が混ざっていた場合、それらも消えます。確実に「一時コミットだけ」消したいなら、最初からscratch branchで分離しておくか、stash＋一時コミットを組み合わせて本作業と切り分けましょう。

worktree先を安易に消す

git worktree add ../fooで作ったworktreeをrm -rf ../fooすると、管理メタデータが残ったゴミ状態になります。必ずgit worktree removeで消すか、誤って消してしまった場合はgit worktree pruneでクリーンアップしましょう。

パッチファイルをコミット範囲の変わる本流で使う

パッチファイルはGit外の存在なので、本流が頻繁に更新されるコード領域に当てるとコンフリクトが多発します。短命な検証なら良いですが、数日以上当て外しを繰り返すならscratch branch＋cherry-pick運用のほうがコンフリクト管理が楽になります。

よくある質問

Qstashと一時コミット、どちらを使うべき？
A「コミットせずに動作確認できる」ならstashが安全です。「コミット済みでないとビルドできない」ならscratch branch上の一時コミット。共有ブランチ上での一時コミットは誤push事故が起きやすいので避けてください。
Qstashした後にブランチを切り替えても戻せる？
Aはい、stashはブランチに紐づかないのでどこでpop／applyしても有効です。ただしコンフリクトが起きる可能性があります。
Q一時コミットを後からきれいに消すには？
A未pushならgit reset --hard HEAD~1で削除。push済みならforce push（個人ブランチ）かgit revert（共有ブランチ）です。rebase -iでdropすることもできます。
Qworktreeとscratch branch、どう使い分ける？
A今の作業ツリーを停止せず別ディレクトリで並行したいならworktree。同じディレクトリでブランチだけ切り替えるならscratch branch。ビルド時間が長い／node_modulesを再生成したくないプロジェクトではworktreeが重宝します。
Qstashにfileだけ選んで退避できる？
A可能です。git stash push -u -- path/to/fileでパス指定で退避できます。また-pオプションでハンク単位でインタラクティブに選べます：git stash push -p -m "部分退避"。
Q一時コミットをpushしてしまった場合の対処は？
A個人ブランチならgit reset --hard HEAD~1＋git push --force-with-lease、共有ブランチならgit revertで打ち消しコミットを追加します。詳しくはpushを取り消す方法を参照。
Q手法を混ぜると逆に混乱しないか？
A混ぜて良いですが、ルールを決めて運用するとよいです：「数分検証はstash、1時間以上はscratch branch、ビルド並行はworktree」など。チームで共通ルールを持つと他メンバーのコードを触るときにも理解しやすくなります。

関連記事

まとめ

  • ローカル動作確認には5手法：stash／一時コミット＋reset／scratch branch／worktree／パッチ
  • 迷ったらstashかscratch branchが安全
  • 一時コミット＋resetは誤pushに注意——scratch branchで分離が無難
  • 並行作業にはgit worktree、固定検証パッチにはgit apply
  • 検証用コミットはWIP:／temp:等のprefixを徹底
  • pre-push hookとBranch protectionで誤pushを予防
  • 検証終了後はscratch branch削除・stash drop・worktree removeでクリーンに

「ちょっと動かしたい」検証作業はGit運用の盲点になりがちな場面です。慣れないうちはstashとscratch branchの2本柱で回し、慣れてきたらworktree・パッチ運用を組み合わせて効率化していきましょう。共有ブランチでの一時コミットは誤pushのリスクを常に抱えます——検証は必ずscratch branchでというチームルールを徹底すれば、レビューもリリース管理もぐっと安定します。