cherry-pick 運用の地獄から這い上がった話をしよう

はじめに はじめに断っておくが、こんな生易しいものじゃない。本当に地獄の沙汰である。 状況と問題点 筆者が参加しているプロジェクトでは、ブランチの運用が cherry-pick で行われていた。Git Flow でも GitHub Flow でもない。言うなれば、Cherry-pick Flow である。 Git Flow について Git Flow なら、本番リリースする際にまず develop ブランチからリリースブランチを切る。 それを master にマージする。 そして、master へのマージ後のマージコミット (M1) を develop に逆輸入すれば、基本的に develop ブランチが Fast-forward な状態となる。 ホットフィックスの場合も同様である。 コミットの取りこぼしなど起きるわけがないし、リリース作業自体もやることが明確でわかりやすい。 Cherry

[programmablekinoko]

一回リポジトリごと捨てて（アーカイブ化して）、新リポジトリとしてやっていくのも必要だよね

[tjmschk]

負債を解消しても特にいいことはなく苦労がなくなるくらいなのが辛いのわかりすぎて😌

[endok]

似たようなことSVNでやってたけど、マージ済みリビジョンがメタ情報に記録されてたからまだマシだったな。コンフリクトの数すごかったけど。

[Magicant]

うちの職場でも割と似た様な枝分かれ運用をしてるけど、ここまでの地獄感はないなあ。何が違ふんやろ?

[takyam1213]

ひょえ〜

[p1ass]

やりきったのすごい

[s_ryuuki]

https://qiita.com/noraworld/items/24650366aff6d80b5186