開発者が誤ってマージに失敗し、空のマージコミットをプッシュしたという問題があります。下の図を参照してください。空のGitマージで削除されたコミット
develop ----A----------------------------------F------------------I
\ / /
feature1 B----------------C----------------------G---------H
\ /
feature2 ------------------------D---------E-----------------------
は、分岐feature1
がdevelop
枝上の点A
で作成されたことを言います。点C
において、feature1
をfeature2
に併合した。ただし、このマージは正しく行われておらず、feature1
(つまり、変更B
とC
の間違って拒否された)からのすべての変更を効果的に拒否したコミットコミットであるコミットコミットD
がコミットされました。
点E
で、feature2
をdevelop
にマージしました。最後に、点H
で、G
とH
をもたらすためにfeature1
をdevelop
にマージしました。
しかし、develop
が変化B
とC
だけでなく、G
とH
を持っていることをポイントI
で期待されています。しかし、彼らは合併時に拒否されたので、私は信じてC -> D
、それはありません。
このシナリオを修正する簡単な方法はありますか?実際には、多くのコミットとマージが悪いマージの後に複数のブランチで発生していることに注意してください。私は点C
でブランチdevelop
ブランチを作成し、これを達成するためにリベースとチェリーピッキングの組み合わせを使用して考えています。しかし、これは非常に面倒なことになるので、状況を迅速かつ安全に救う方法は非常に高く評価されます。
:
(
A
にfeature2
に知られているコミットが間違ってD
マージが最後から歴史をB
とC
ないだけを元に戻すだけでなく、develop
ことに注意してください)手順のようなものでなければなりませんあなたのダイアグラムでは 'G'というラベルが付いていますが、異なっているようです。 「F」であると思われますか? – torek
@torekはい、あなたは正しいです。一定。 – Dunnie
あなたの計画はかなり正しい方法だと思います。'git rebase'は' git merge'が* new *(must-merge)とみなすコミットをコピーするのを助けるために '-f' /' --no-ff'を持っていることに注意してください。過去にはるかに多くのリワーク(チェリーピックまたはマージのいずれか)に直面するでしょう。 – torek