【正しいgit操作】stashするならcherry-pickをしよう

[ad#co-1]

たまに「stashしとけば？」とか「stashみすった！」とかを聞くことがありますが、僕は声を大にして言いたい。

stashなんて絶対にするな！

これに尽きます。
なんでかってあまりにメリットが少ないわりに事故る確率が高いんですよね。
それなら使わないほうがよくないですか？っていう記事です。
基本的にGitコマンドでの説明ですが、SourceTreeでもstashってできるらしいので、SourceTreeユーザーも対象の記事です。

他のGitコマンド操作の記事はコチラから。

stashのメリット

stashすると変更が自分のlocalのgit内に一時てきに保存されます。
他のブランチに切り替えて、その変更を適用することが目的です。
なので、素早く開発を進めることができます。
それが一番のメリットです。

逆にいうとそれ以外のメリットはありません。

stashのデメリット

メリットでお伝えしたようにたしかに少し早い開発が実現します。
僕からしたら制限速度を少し超えて走っている車みたいなもんです。
ややはやく目的地には着くけど、事故率は上がります。
そこで僕の感じるデメリットをお伝えします。

localとしてのgitは一箇所しかないのに、様々なブランチのstashがたまる

これの何が問題か。
それはstashを戻す際に「戻すstashを間違える」ことと「stashが多すぎて管理どれを戻すのかを迷う」ことです。
前者は事故に直結しますし、後者は時間の無駄です。

DBのテーブル設計する人ならわかるかと思いますが、「このテーブルにそのデータ入れるのは。。。テーブル分けようよ。」その感覚と一緒です。
自分でしっかり整理できていればいいですが、いつもいつもそんなうまくいきますか？
stashをチームの当たり前にすると、その整理を一定のクオリティでみんなができますか？

PCが壊れたら終了

せっかくstashをしたけどlocalでしかデータがないので、PCが壊れたらおしまいですよね。。。
なんのためのクラウドでしょうか。
それならGitHubやBitBucketにpushしておくほうが安全じゃないですか？

もし、開発期限締切日に自分が体調壊して会社に行けなかったら？
stashは会社にある自分のPCにしかない。。。
誰も助けることはできませんよね。

リスクヘッジができない。

これもデメリットの一つです。
開発者であれば常に何か起こったとしてもなんとかできる体制を作っておくべきではないでしょうか？

[ad#co-2]

stashの代わりにcherry-pickを使うという選択肢

上記のデメリットからstashを勧めない理由が伝わったかと思います。
その代わりの提案としてのcherry-pickという選択肢です。

stashしたくなったらまずはブランチを新しく生やします。

git checkout -b hogehoge_2

みたいな感じで。
それをpushしておきます。
するとクラウドにあるので安心ですよね。

次にそのブランチを他のブランチに反映させたい場合は新しくきったブランチのcommitハッシュ値を取得します。

git log –oneline

変更を適用したいブランチに切り替えて、cherry-pickを行います

git cherry-pick （commitハッシュ値）

こうすれば何も問題なくstashで実現したかったことが実現できます。
stashのデメリットも解決できます。

1. ブランチごとに_2で新しくブランチを切るので、どのcommitをcherry-pickすればいいかが明確になる。
2. クラウドに存在するので、チームメンバーなら誰でもアクセスできる。

この方法でのデメリットはstashのメリットがなくなるということです。
新しくブランチを切らないといけないし、pushもしなければいけない。
しかし、Gitコマンドの回数で言えばほぼ変わらないと思います。

それであれば確実に、かつ迷うことを減らす方法でやってみませんか？という提案です。
効率よくかつ事故のない開発を心がけていきましょう。