ここでちょっとした問題に遭遇しました。Git28sに問題のあるブランチがあり、それを一般developブランチにマージしました。あまりにも急いでいたことが判明したので、git-revert を使用してマージを元に戻しました。しかし、今度28sは にマージする時が来たのですdevelopが、git-merge コマンドは元のマージを確認し、すべてが順調でブランチがすでにマージされていることを喜んで通知します。次に何をすればよいでしょうか。「Revert "Revert "28s -> developer"" 」コミットを作成しますか。良い方法ではないようですが、現時点では他の方法は思いつきません。
ツリー構造は次のようになります。
ベストアンサー1
「元に戻す」必要があります。元の状態に戻す方法によっては、思ったほど簡単ではないかもしれません。このトピックに関する公式文書。
---o---o---o---M---x---x---W---x---Y
/
---A---B-------------------C---D
許可する:
---o---o---o---M---x---x-------x-------*
/ /
---A---B-------------------C---D
しかし、すべてうまくいくのでしょうか? もちろん、うまくいきます。マージを元に戻すことができ、純粋に技術的な観点から言えば、git はそれを非常に自然に実行し、特に問題はありませんでした。
単に「マージ前の状態」から「マージ後の状態」への変更とみなしただけで、それで終わりでした。
複雑なことは何もなく、奇妙なことも、特に危険なこともありません。Git は何も考えずにそれを実行します。したがって、技術的な観点からは、マージを元に戻すことに何の問題もありませんが、ワークフローの観点からは、通常は避けるべきことです。
たとえば、メイン ツリーにマージされた問題を見つけた場合、可能であれば、マージを元に戻すのではなく、次のことを確実に実行してください。
- 問題をマージしたブランチに分割して修正するだけです。
- または、原因となった個々のコミットを元に戻してみてください。
はい、より複雑です。また、常に機能するとは限りません (時々、「おっと、まだ準備ができていなかったので、マージするべきではなかった。マージをすべて元に戻す必要がある」という答えが返ってきます)。その場合、マージを元に戻す必要がありますが、マージをやり直す場合は、元に戻すを元に戻す必要があります。