7

以前のリベースで競合がすべて解決されていた場合に、リベースが以前のリベースからの競合を繰り返す一般的な理由はありますか?
さらに、リベースは、競合がどのように解決されたかより優先されますか? たとえば、リベースは、コード内の通常の git 競合ブラケット内の 2 つの可能なコード スニペットの間で厳密な選択を必要とし>>>ます<<<か? 競合を解決するために両方のコードの選択肢を削除すると、後の競合を適切に解決するリベースの機能に影響するかどうか興味があります。

さらに詳しく説明します。masterブランチとdevブランチがあります。私がしばらくの間サイドで取り組んできたdevブランチなので、異なるコミットの数は 100 代でかなり大きくなりました (私は知っています...もっと頻繁 devにすべきです)。ブランチ自体には、いくつかの小さな機能ブランチがカットされてからマージされており、カットされ、リベースされ、ブランチとマージされ、ブランチされることはありませんでした (私が覚えていることです)。1週間前にブランチをブランチにリベースしました。それ以来、ブランチにさらにいくつかの変更を加え、マージの準備ができるようにもう一度リベースしたいと考えています。非常に小さな変更がありましたmasterdevdevmasterdevmasterdevmastermasterその 1 週間のウィンドウでも分岐しますが、コード ファイルは重複しません。ただし、リベースすると、1 週間前にリベースdevmasterたときと比較して、現在のリベースを試みるときに git によって同じ一連の競合が発生していることがわかります。

ありがとう!

4

1 に答える 1

9

一般に、これは正常です。マージするのではなく、このようにリベースする場合 (たとえば、master を dev に)、同じパッチを再生すると、同じ競合が発生する可能性があります。

これがワークフローでよくある問題である場合は、git rerereを使用して解決策を思い出すことができます。

于 2016-04-13T17:25:42.833 に答える