Question

在将我的更改与上游主人合并时，我经常发现自己在执行以下操作：

git checkout somefeature
git checkout -b integration
git rebase master # resolving conflicts along the way
git checkout somefeature
git merge integration # or rebase, doesn't matter in this example

我经常会发现将集成分支合并回我的功能分支会导致一些冲突失败。我遇到的第一个问题是，“如果我的集成分支是某个特征的后代并且我已经解决了与上游主人的冲突，为什么会发生这种情况？”

如果您想知道为什么我开始使用集成分支，那就是防止以半失败的合并来污染我当前的分支。

我目前的解决方法是：

git checkout integration
git branch -f somefeature # overwrite the branch

现在的问题是我无法将我的更改推回到远程分支：

git push origin somefeature
! [rejected]        somefeature -> somefeature (non-fast forward)

所以现在我必须删除远程分支并重新推送我的更改。这不是最佳方式，所以我想知道，“覆盖分支并将更改推送到远程分支的最佳方法是什么？”

Answer 1

问题是由于git rebase生成了一系列新的提交而不是来自somefeature分支，然后当您尝试将它们合并回somefeature冲突解决方案时在rebase期间完成不适用。如果您只是合并而不是rebase，那么这将起作用，因为合并提交将从somefeature分支下降。

在推送到远程分支方面，你可以使用--force使推送成功，这会给任何拥有副本的人造成问题。

Answer 2

您可以使用git merge -s recursive -Xtheirs，这将自动解决有利于集成分支的冲突。但是，这仍然会合并，并且可能无法很好地处理文件移动等。

但是，由于您的分支被推送，您有理由想要保留其历史记录。为了获得您想要的理想行为，您可以在集成分支中使用“我们的”策略。

git checkout somefeature
git checkout -b integration
git rebase master # resolving conflicts along the way
git merge -s ours somefeature # mark integration as superseding the somefeature branch
git checkout somefeature
git merge integration # this is now a fast-forward, no conflicts

Answer 3

您可以确保最终合并使用合并驱动程序覆盖目标分支：
例如，请参阅“Can I tell git pull to overwrite instead of merge?”。

我们的想法是拥有custom merge driver with a "keepTheir" script。

Answer 4

你的第一点操作很奇怪。你复制了一些特征。你反对主人。然后你回到那个功能，并将其与自身的重新设置的等效项合并。这不是做事的方式。

不要过于复杂化。如果你想让功能分支从其他地方开始（比如最新的主设备），只需重新设置它。

然后用--force（或-f）推送它。告诉其他正在使用该功能分支的人，他们必须获取更改并调整他们本地没有推送的任何内容。

当其他人一直在努力时，合并会更好。

希望这有帮助。

覆盖和推动Git分支

4 个答案: