以前のリベースで競合がすべて解決されていた場合に、リベースが以前のリベースからの競合を繰り返す一般的な理由はありますか?
さらに、リベースは、競合がどのように解決されたかより優先されますか? たとえば、リベースは、コード内の通常の git 競合ブラケット内の 2 つの可能なコード スニペットの間で厳密な選択を必要とし>>>
ます<<<
か? 競合を解決するために両方のコードの選択肢を削除すると、後の競合を適切に解決するリベースの機能に影響するかどうか興味があります。
さらに詳しく説明します。master
ブランチとdev
ブランチがあります。私がしばらくの間サイドで取り組んできたdev
ブランチなので、異なるコミットの数は 100 代でかなり大きくなりました (私は知っています...もっと頻繁 dev
にすべきです)。ブランチ自体には、いくつかの小さな機能ブランチがカットされてからマージされており、カットされ、リベースされ、ブランチとマージされ、ブランチされることはありませんでした (私が覚えていることです)。1週間前にブランチをブランチにリベースしました。それ以来、ブランチにさらにいくつかの変更を加え、マージの準備ができるようにもう一度リベースしたいと考えています。非常に小さな変更がありましたmaster
dev
dev
master
dev
master
dev
master
master
その 1 週間のウィンドウでも分岐しますが、コード ファイルは重複しません。ただし、リベースすると、1 週間前にリベースdev
しmaster
たときと比較して、現在のリベースを試みるときに git によって同じ一連の競合が発生していることがわかります。
ありがとう!