昔の自分の書いた記事って恥ずかしいですよね。
数年前自分が書いたqiit（勘違いしていたGit stash）を読み返してものすごく恥ずかしくなりました。

あの頃の自分とは違い git stash を上手に使えるようになったのでまとめてみました。今回はgit stashの使い方というより、使い所についての記事になっています。

基本コマンドは以下のコマンドしか使いません。使い分けとかは面倒なので、

git st 'hogehoge'

とうてば

terminal

git stash save -u 'hogehoge'

と同じようになるようにエリアス化しています。

上記コマンドを知らない人ように少し説明すると、

-uオプションをつけることで、untrackedなファイルも一緒にstashできます。
saveをつけることで、コメントを残すこともできます。

本題。

その１　いきなり緊急タスクが降ってきた

これは多くのかたが使うやり方だと思います。
issuesAを実装しているときに、バグ見つかったからこっち先やってくんね？と言われたら迷わず
git stash save -u 'hogehoge'をうって、ブランチを移動します。タスクが終わったらブランチに戻ってきて、
git stash popをすればOKです。

その２　この実装は別ブランチでやりたいな

ブランチ運用の話を少しします。

振る舞いに(behavior)よってbranch分けをします。
例えば、「ある外部APIからデータを取得し、アプリケーション側でデータを修正・保持しておいて、そのデータを取得できるAPI実装」というタスクを実装する際に
以下のようにブランチ分けをします。

実装に必要なものをセッティングするためのbranch
feature/initialize　branch

外部APIからデータを取得できるようにするbranch
feature/get-data　branch

取得したデータを修正・保存できるようにするbranch
feature/update-data　branch

保持してあるデータを取得できるようにするbranch
feature/get-hoge　branch

イメージはこんな感じです。

で、例えば保持してあるデータを取得できるようにするを実装している際に、
取得したデータを修正・保存できるようにするの実装でバグや改善点を見つけて修正・追加したときにstashを使って一時避難しておきます。
feature/update-data　branchで修正したら、元いたブランチに戻ってきて、feature/update-data　branchをマージしてもいいんですが、僕は元いたブランチを一旦削除して、再度**feature/update-data**　branchから分岐させます。（commitを綺麗に保ちたい。。。）作り直したブランチでstash popを実行すれば、元どおりになります。

その３　この実装別ブランチの方が良かったじゃんね？

こんなときないですか？僕は結構あります。
その２の時みたいにブランチを細かく分けていて、すでに実装の終盤で別ブランチの方が良かったと気付いた際に今いるブランチで、PR出したいものだけをadd&commitしておいて、別ブランチからRPをあげたいものをstashして、該当ブランチに移動、stash popしてからadd&commitするなんてことも最近はやっています。

まとめ

以上で、最近僕がstashを使う時はこんな時！！というのをまとめました。
上記の運用だと多少面倒ではありますが、レビューワーのことを考えると、なるべく細かい振る舞いごとにPRを作ることでレビューもしやくなると思うので、stashを活用してブランチ分けを気にかけてみてください。

他にもこんなときにstashを使う！！などありましたら是非コメントしてください。