git stash popとは?使い方を初心者向けにわかりやすく解説
はじめに
ソフトウェア開発では、複数のブランチを行き来しながら機能追加やバグ修正を行うことが多いです。
そのようなとき、現在の作業内容を一時的に保管して別の作業へ素早く切り替えるためにgit stash
はとても便利です。
しかし、いざ保管していた変更を復元しようと思うと、どのコマンドを使えばよいか迷う方も多いのではないでしょうか。
ここで登場するのがgit stash pop
です。
一時保管した変更を再適用するうえで役立つコマンドですが、使い方を間違えるとコンフリクトが発生したり、意図しない形で作業内容が混ざってしまうリスクもあります。
そこで本記事では、初心者の方向けにgit stash pop
の使い方を中心に解説します。
実務で想定されるシーンや、よくあるエラー事例などにも触れながら具体的に説明しますので、ぜひ最後まで読んでみてください。
この記事を読むとわかること
git stash pop
の基本的な役割と動作- 実務における具体的な使用シーン
- 衝突(コンフリクト)などが起きたときの対処法
- 複数のstashを扱うときの注意点
git stash popの概要
まずは、git stash popがどういったコマンドなのかを押さえておきましょう。
git stash pop
は、現在の作業ツリー(ワークツリー)へ過去にstashした(一時保管した)変更を適用し、そのstashをstash一覧から削除するという動きをします。
たとえば、作業中に別のブランチへ急ぎで切り替える必要があるケースを想像してください。
一度コミットするほどでもない中途半端な変更が残っていて、コミットしてしまうと履歴に不要なメッセージが残ってしまう場合もあります。
そうしたときにgit stash
コマンドで変更を一時的に隠しておき、用事が終わったらgit stash pop
で隠していた内容を再適用するわけです。
このような流れをもう少し詳しく見てみましょう。
stashした内容は複数まとめられるので、git stash list
を使うことで現在どういったstashが保管されているか確認できます。
そして、必要なものを選んで再適用するときにgit stash pop
を使うのが基本となります。
具体的には、次のようなコマンドを打つことが多いでしょう。
git stash list git stash pop stash@{0}
上記では、stashの一覧から最も最新のstash(stash@{0}
)を再適用しています。
また、git stash pop
だけで実行した場合も、同じように最新のstashが再適用されます。
実務と紐づけた基本的な使い方
ここでは、初心者の方が実際に作業している場面を想定しながら、git stash pop
の使い方をもう少し詳しく解説します。
突発的に別ブランチで修正が必要なとき
開発を進めていると、突如「別のバグを先に直してほしい」という指示を受けることがあります。 そのとき、現在のブランチで進めていた作業は中途半端ですが、まずはいったん中断しなければいけません。
1. 変更内容を一時保管
git stash
2. 修正が必要なブランチに移動して作業
git checkout hotfix-branch
3. 修正完了後、元のブランチに戻る
git checkout feature-branch
4. 再度作業を再開したいのでstashを取り出す
git stash pop
このようにすれば、無駄なコミットを残さずに作業を中断・再開できます。
また、stashを適用したタイミングでstashが削除されるので、一覧をすっきり保てるのもgit stash pop
の特徴です。
途中でブランチを切り替える頻度が高いプロジェクト
実務では、ひとつのブランチで作業をしている最中に、別の機能やバグ対応に切り替えることが珍しくありません。 たとえば、テストブランチで動作確認中に軽微な修正が必要になったり、デザイン変更への対応を要求されたりする場合があります。
こういった場面でも、git stash pop
を使って一度隠していた変更を無駄なく再適用できます。
仮に作業が細かく分割されていてもstashを活用することで、一時的に保管しながらスムーズに切り替えられるのです。
よくある使用シーンと注意点
git stash pop
を使うメリットは大きいのですが、いくつか注意点があります。
間違った使い方をしてしまうと、作業内容が混ざり合い、どこに何が入ったのか分からなくなるリスクもあるため、以下を意識してみてください。
stashを使い過ぎると混乱しやすい
stashはあくまでも一時保管の仕組みであり、変更内容を安全に長期間保管しておくものではありません。 必要以上にstashを増やすと、あとで自分自身がどのstashに何が含まれているか分からなくなる可能性があります。 特に、同じブランチで何度もstashを溜めるケースでは、命名やメモを使うなど整理が重要です。
# stash時にメッセージを残す例 git stash save "作業途中のUI修正" git stash list # => stash@{0}: On feature-branch: 作業途中のUI修正
こうしておけば、あとからgit stash list
を確認する際にも整理しやすくなります。
stashした内容を別ブランチでpopするとき
あるブランチでstashした変更を、別のブランチでgit stash pop
することも技術的には可能です。
ただし、この方法はコンフリクトが起きやすいので、慣れていないうちは避けた方が無難でしょう。
変更内容が別ブランチのコードと競合している場合、コンフリクトが発生する可能性が高まります。 加えて、大きく構成が異なるブランチ同士でstashを適用すると、意図しない形でコードが混ざるリスクもあります。
どうしても別ブランチでpopしたい場合は、事前にstashの対象ファイルやブランチ構成を十分に確認してから行いましょう。 コンフリクトの対応に時間がかかる場合もあるため、作業効率が落ちるリスクがあります。
git stash popとgit stash applyの違い
stashを再適用するコマンドとして、git stash apply
もよく取り上げられます。
では、popとapplyの違いは何でしょうか。
git stash pop
stashの内容を適用したあと、stash一覧から該当のstashを削除する
git stash apply
stashの内容を適用するが、一覧から削除しない
つまり、popは再適用と同時にstashを削除し、applyは再適用してもstashが残るという点が最大の違いです。
「削除は後から行いたい」「とりあえず再適用して動作を見たい」といったケースでは、git stash apply
を使うと良いでしょう。
ただし、applyの場合はstashが残り続けますので、不必要にstashが溜まってしまうと管理が煩雑になります。 状況に応じてうまく使い分けてください。
コンフリクトが発生した場合の対処
git stash pop
を適用する際、元のブランチとstashの変更内容が衝突してしまうことがあります。
コンフリクトが起きたら、基本的には通常のコンフリクト解消と同じ流れで対処してください。
- 衝突箇所をエディタで確認し、必要なコードを手動でマージする。
- コンフリクトマーク(
<<<<<<<
や=======
など)を取り除き、ファイルを正しい状態に整える。 - 変更をステージングしてコミット。
コンフリクトに焦ると、つい大事なコードを誤って削除してしまうケースもあります。 stashを適用するときは、落ち着いて作業内容を比較しながら進めるとよいでしょう。
コンフリクトはエラーではなく「どちらを採用すべきか分からない」という状態です。 エディタの機能を活用し、差分をしっかり見比べてコードを整理しましょう。
複数のstashを扱うテクニック
stashは複数保管可能であり、時系列で管理されています。 複数のstashを安全かつ分かりやすく扱うためのポイントを押さえておくと、より効率的に作業が進められます。
stashの一覧を常に確認する
複数のstashを溜めていると、どれが最新でどのブランチでstashしたものか一目では分かりません。
そこで、git stash list
を習慣的に使って、どんなstashがあるのか把握しましょう。
stash作成時にメッセージを付けておけば、より分かりやすくなります。
git stash list # stash@{0}: On feature-branch: 作業途中のUI修正 # stash@{1}: On feature-branch: 新規API連携の追加 # stash@{2}: On main: Hotfix for login bug
古いstashを狙い撃ちしてpopする
最新ではないstashを適用する場合、git stash pop stash@{n}
のように指定します。
次の例では、2番目に古いstash(stash@{1}
)を再適用しています。
git stash pop stash@{1}
このとき、指定したstashが適用と同時に一覧から削除される点は変わりません。 複数のstashを取り扱う場合は、どのstashを再適用するかしっかり把握してからコマンドを打ちましょう。
実務での活用シーン
実務の現場では、以下のようなシーンでgit stash pop
を積極的に活用することが多いです。
レビュー待ちの間に別の作業へ着手する場合
レビュー依頼を出したものの、承認されるまで時間がかかるときは、次のタスクにスムーズに切り替えられます。
開発環境とテスト環境を頻繁に行き来する場合
ある環境でのテスト実行中に、別環境で急ぎの修正が必要になったときなど。
小さな修正や細かい調整が頻繁に発生するプロジェクト
たとえばUIの微調整や文言修正など、コミットにまとめるほどではない変更が多いときに便利です。
このように、stashとpopの組み合わせはチーム開発でも個人開発でも役立ちます。 うまく使いこなせば、開発の生産性が上がり、余計なコミットを増やさずに済むでしょう。
エラー事例とその解決策
ここでは、初心者の方がよくつまずくエラーや状況をいくつか紹介します。
stashが適用できない
stashが適用できない場合、主な理由として以下が考えられます。
- 対象のファイルがすでに削除されている
- ブランチ構造が大きく変わっている
- 手動でファイルの内容を変更してしまい、実際の差分が変わっている
対処としては、stashしたブランチとpopするブランチが合っているか、あるいはstashの適用先となるファイルが存在するかを確認しましょう。
どうしても適用が難しそうなときは、git stash apply
で試したり、ファイルの差分を個別に確認して手動で移植するなどの方法を取ることもあります。
conflictが起きてstashが中途半端に適用された
conflictが発生すると、stashの変更が一部しか適用されず、作業ツリーが中途半端な状態になるケースがあります。 このときは焦らずに、通常のコンフリクト解消と同様にファイルを編集し、正しい状態に整えたあとステージングしてコミットしましょう。
場合によってはstashが削除されているため、再度popできないということも起こります。 もし誤って必要な変更が消えてしまった場合、リポジトリの履歴や別のstashからの復元を検討する必要があります。
よくあるQ&A
初心者の方が疑問に思いやすい点をまとめました。
stashとコミットの違いは?
コミットは履歴として正式に残すもので、stashは一時的に変更を退避させるための仕組みと考えてください。 コミットで記録してしまうと、Gitのログが散乱したり、不要なコミットが混ざったりしがちです。 stashはあくまで作業を中断・再開するための手段なので、正式に履歴を残したい場合はコミットを行います。
stashを使い忘れて切り替えた場合はどうなる?
stashをせずにブランチを強制的に切り替えると、変更が作業ツリーに残ったままの状態になります。 そのまま他のブランチでコミットしてしまうと、意図しない差分が入り込み、トラブルの原因になるでしょう。 意図しないコードが混ざっていないか、差分を常に確認しながら開発を進めるのが大切です。
stashに期限はある?
stashした内容そのものに明確な期限はありませんが、古いstashを放置していると、自分自身が何をstashしたのか忘れる可能性が高いです。 結果的に「必要ないかも」と思ってそのままにしてしまい、コードの整合性が保てなくなるケースも考えられます。 定期的に不要なstashを削除するなど、管理を徹底しましょう。
まとめ
git stash pop
は、一時保管していた変更を再適用し、stash一覧から削除する便利なコマンドです。
少しの手間で別ブランチに作業を切り替えたり、不要なコミットの乱立を防ぐことができます。
ただし、stashを乱用してしまうと、どのstashに何が入っているか分からなくなったり、別ブランチでpopしてコンフリクトが頻発したりと混乱を招くリスクも存在します。 実務の現場では、小さな修正や突発的なタスクが多発することもあるため、stashとpopの使い方をマスターしておくと安心です。
特に複数のstashを管理する際は、stashにメッセージを付けておく、使用したstashは速やかに削除するなど、運用上の工夫をすることがポイントです。
それぞれの場面に応じてgit stash pop
を上手に使いこなし、作業効率を高めていきましょう。