前回の検証でまずいという事が判明した。
gitで間違ってmergeしてしまったものをrevertして再度mergeするとどうなるかを検証する。 - 画竜点睛を衝く@mapyo
これに対応する為に、qiitaに投稿したところ、いくつか対応案を頂いたので、 それを検証してみたいと思う。今回は案を書くだけ。
その前に、前提を書く。
前提
- チームで開発している
- githubとかそういう系を使ってる
- グループで共有してリポジトリを使っている
- gitに不慣れな人もいるため、出来ればrebaseを使いたくない。
- それなりに大きな修正で50%くらい作業した段階で間違ってやっちゃったパターン
対応案
シナリオ1
- 開発中のhogehogeブランチで作業中、間違ってmasterにマージしてpushしてしまった!!
- 間髪入れずに周りの人にごめんなさいして、マージされる前の状態にmasterを戻す。
- push -f 使う。
これが一番いいような気がする。
シナリオ2
- 開発中のhogehogeブランチで作業中、間違ってmasterにマージしてpushしてしまった!!&他の人が既にcommitしてしまってた!
- masterにマージした内容をリバート&push ここでひとまず、masterは安心。
- masterの内容をhogehogeブランチにmergeする。
- masterでrevertした内容がhogehogeブランチ上でなかった事にされてしまっているので、hogehogeブランチ上でmasterでrevertした内容を再度revert
- masterでは開発が進む
- hogehogeブランチでも開発は進む
- hogehogeブランチで開発が終わったので、hogehogeブランチの内容をmasterに反映させる。
上の次にこれがいいような気がする。 (rebase恐怖症)
シナリオ3
- 開発中のhogehogeブランチで作業中、間違ってmasterにマージしてpushしてしまった!!&他の人が既にcommitしてしまってた!
- masterにマージした内容をリバート&push ここでひとまず、masterは安心。
- masterにマージ済みのところから生えるようにhogehogeブランチをrebaseして作業を続ける
- masterでは開発が進む
- hogehogeブランチでも開発は進む。
- hogehogeブランチで開発が終わったので、hogehogeブランチの内容をmasterに反映させる。
本当は履歴が綺麗になるからこの方法がシナリオ2よりもいいと思う。
シナリオX
そもそも、masterに直接push出来ないようにして、全てプルリクベースでmasterにmergeするようにする。 (そんな事出来るのかな。。。)
結論
書いている間にだいぶ熱が覚めて来た感があるので、もしかしたらこのシリーズはこれで終わりになるかもしれませんw