git stash した変更を元に戻すには？初心者向けにわかりやすく解説
はじめに
Gitで作業を進めていると、作業中に急遽別のブランチへ切り替えたい場面が出てくることがあります。 しかし、まだ途中の変更はコミットしたくない、あるいはコミットが増えすぎると履歴が煩雑になるという悩みをお持ちではないでしょうか。
そんなときに活躍するのが git stash です。 これは編集途中のファイルを一時的に退避（保存）し、必要になったら再度呼び出して適用できるGitの機能です。 特に初心者の方がつまずきやすいのは、stashした内容をどのように「戻す（復元する）」かという点ではないでしょうか。
本記事では、 git stash 戻す 方法を中心に、具体的なコマンド例やトラブルシューティングなどを交えながらわかりやすく解説します。 実務でよくあるケースを想定して、実際にどのように活用できるのかも一緒に見ていきましょう。
この記事を読むとわかること
- git stash の基本的な概念と役割
- stashした内容を戻すためのコマンドと使い方
- コンフリクトが起きた場合の対応方法
- 実務で役立つ stash の運用例
git stashとは何か
初心者の皆さんにとって、まずは git stash の位置づけを明確にすることが大切です。 Gitには、作業内容をステージングエリアへ追加したり、コミットするといった操作が存在します。 しかし、作業中に中途半端な状態でコミットを増やすと、履歴が細切れになって後で整理しづらくなる可能性があります。
そこで、コミットはしたくないが変更は残しておきたい、というケースにstashが役に立ちます。 stashを使うと作業ツリー上の変更が「一時的に保存」され、ローカルのワークツリーは変更前のクリーンな状態に戻ります。 一度stashに入れた変更は、後から好きなタイミングで「取り出す」ことが可能です。
たとえば「Aという作業をしていたが、急にBというバグ修正ブランチを切りたい」というときに、大変役立ちます。 stashは複数回重ねて保存できるので、何度でも変更を積み重ねられる点も覚えておくと便利でしょう。
git stashを使う実務イメージ
git stash は、単なるコマンドの知識だけでなく、どんなシーンで使うかが重要です。 ここでは、実際の業務でよく起こるシチュエーションを簡単に示します。
あるフロントエンド開発をしているときに、スタイルの調整作業途中でサーバーサイドの不具合修正を急いで対応しなければならない場面を想像してみてください。 途中のスタイル変更はコミットしてしまうと履歴が混ざり、後々見返す際に混乱しやすくなるかもしれません。
そこで、まだ完成していないスタイル変更を git stash で一時的に退避させます。 そして別ブランチを切って不具合修正に集中できるようにするわけです。 修正が完了したら、再び先ほどのスタイル調整ブランチに戻り、stashを復元して作業を再開します。 こうすることでコミット履歴をスッキリ整理しながら、優先度の高い作業にも素早く切り替えができます。
git stash は、複数の開発案件が同時並行で動く現場で非常に便利なテクニックです。
git stash 戻す を行う基本的なコマンド
stashに入れた変更を再びワークツリーに取り戻すには、以下のコマンドを使います。
stashを戻すためのキホン
stashを使った代表的な操作は、次の2つです。
- git stash apply
- git stash pop
どちらもstashに保存された変更をワークツリーに適用しますが、それぞれ特徴が少し異なります。
- apply は stashの内容を再適用するだけで、stash自体は削除されません。
- pop は stashを適用した後、適用に成功すると自動的に stash の最新エントリが削除されます。
たとえば、最新のstashを適用したい場合は、以下のように実行します。
git stash apply
stashのリストが複数存在していて、その中から特定のstashを戻したい場合は、以下のようにstash番号を指定します。
git stash apply stash@{1}
番号の部分は git stash list で確認できます。
一方で、stashを戻したあとにリストから消したい場合は、以下のようにします。
git stash pop
こちらも特定の番号を指定可能です。
git stash pop stash@{1}
applyとpopをどちら使うべきかは、状況によって異なります。 複数のstashを残したい場合や、間違って消したくない場合は apply が安心です。
stashを戻す際の衝突(コンフリクト)対応
stashを戻すときには、別ブランチで既にファイルが変更されていたりすると、コンフリクトが発生することがあります。 これは、Gitがそれぞれの変更箇所をうまく統合できず、どの変更を採用すべきか判断できない状態です。
コンフリクトが起きた場合は、通常のマージ衝突と同様、対象ファイルにマージコンフリクトの印が挿入されます。 その印を目印にして、どの部分を残すか手動で編集し、コミットすれば解決です。
<<<<<<< Updated upstream
... すでにブランチにあった変更内容 ...
=======
... stashから持ってきた変更内容 ...
>>>>>>> Stashed changes
stashとブランチの内容が競合するケースは、特に同じ箇所を変更していたときによく起こります。 実務では「急いで stashから戻したらコンフリクトが山ほど出てきた」ということもあり得ますが、ひとつひとつ手動で解決すれば大丈夫です。
コンフリクトの解消を中途半端にすると、今後の作業で思わぬ不具合が発生する可能性があります。 解消後は必ずファイルの変更内容を確認し、最終的にコミットしてから次の作業に進んでください。
複数のstashから選択して戻す方法
複数回にわたって stash を実行すると、それぞれがリストとして積み重なっていきます。 そのとき、どのstashが何の作業を中断したものだったかを把握しておかないと混乱しがちです。
まずは下記でstashの一覧を確認できます。
git stash list
すると、たとえば以下のように表示されます。
stash@{0}: WIP on feature/header-update
stash@{1}: WIP on feature/footer-fix
stash@{2}: WIP on master
戻したいstashが決まったら、 stash@{n} の番号を使って復元します。
git stash apply stash@{1}
これで stash@{1} の内容だけが適用されます。
続けて別のstashを適用する際は、同じように番号を指定しましょう。
また、popでも番号を同様に指定できます。
このように特定の stash を選んで戻すことで、複雑に管理しなければならない作業状況でも柔軟に切り替えが可能です。 ただ、あまりにも stash を溜めすぎると何がなんだかわからなくなる場合があるので、適度にコミットをまとめるか、使わなくなったstashは消去して整理すると良いでしょう。
stashをbranchに展開する方法
stashに保存されている作業内容が多い場合、コンフリクトやファイルの細かな差異を手作業で調整するのは大変です。 そこで便利なのが、stashをもとに新しいブランチを作成する方法です。 以下のコマンドを使います。
git stash branch 新規ブランチ名 stash@{n}
これによって指定したstashの内容がすべて適用された新しいブランチが自動的に作成されます。
例えば stash@{0} を feature/stash-test という名前のブランチで展開したい場合は、以下のようにします。
git stash branch feature/stash-test stash@{0}
新規ブランチが作成され、そのブランチに切り替わった状態になります。 このやり方のメリットは、元のブランチの状態を壊すことなく stashの内容を復元し、分岐して作業を続行できる点です。 復元後に衝突があっても、別ブランチで作業しているので安心して衝突解決や追加修正が行えます。
一度stashをブランチ化すると、そのstashエントリは消えます。 ブランチ側へ移管してしまうので、余計なstashが増えることはありません。 これも stash を使いこなすうえで便利なテクニックのひとつです。
まとめ
ここまで、 git stash 戻す 方法や実務での活用イメージ、コンフリクト対応などを紹介しました。 stashは、チーム開発の現場でも個人開発でも役に立つコマンドです。
途中で作業内容を分割したり、突発的なバグ対応やブランチ切り替えに柔軟に対処したりする際にはとても便利です。 特にコンフリクトが起きたときの対応や、stashの複数管理に慣れておくと、よりスムーズに作業を進められるでしょう。
stashした内容を戻す際には、以下の点をおさえておくことが大切です。
- apply と pop の違いを理解する
- stash番号を正しく指定して、意図した変更のみを戻す
- コンフリクト対応は丁寧に行う
- 必要に応じて stash からブランチを切る方法を活用する
こうしたコツをつかみながら、ぜひ stash を使いこなし、作業効率の向上につなげてみてください。