合并前如何解决合并冲突

Question

当我尝试将feature分支合并到master ，有时会遇到合并冲突。

现在显而易见的解决方案是仅在合并过程中手动解决冲突。

但是，在基于拉式请求的工作流（github，gitlab等）中，这在某种程度上是次优的，因为它将所有工作交给负责实际合并分支的人员，而不是提交者。

一种有用的解决方案是在提交PR之前将master合并到feature ，从而解决所有冲突。 但是，我觉得这不必要地使git历史复杂化。

所以我想知道是否有一个（简单）的方式来准备feature的分支，因此可以干净地合并到master （事实上，这两个分支都显著分歧后 ）。 理想情况下，修复可以在多个提交中完成。

Answer 1

当可以覆盖feature分支时，可以在提交拉取请求之前（或同时在master上引入重大更改之后）使用rebase 。

重新设置基准不会创建其他“合并”提交。 它将通过创建新的提交（新的SHA）来重写历史记录。 您可以在git-scm.com/docs/git-rebase上阅读有关它的更多信息。 另外，请参阅有关merge和rebase命令之间差异的文章。

在代码审查过程中，重新定基也很有用。 您可以提交新的拉取请求，以便其他人可以删除评论。 然后，您可以通过添加fixup commits来改进代码。 您的团队可以再次进行代码审查，但是现在他们只能检查新引入的更改。 最后，您只需要重新整理所有fixup提交的内容 ，强制推送分支并合并代码即可。

请注意，仅当您单独在该分支上工作时，此方法才可行。 当有其他人在同一分支上工作时，您永远不应更改分支的历史记录（并强制推送）。

Answer 2

我不知道 我认为最简单的方法是将master合并到feature分支中，然后再提交给拉取请求（PR），如您在问题中所述。 这就是feature分支可以与master节点干净合并的方式。 我不知道它是否简单，但是干净。

我个人遵循广泛使用且相当普遍的项目结构的一些基本准则。 首先，面向对象的项目结构以及适当的包装可以有效避免合并冲突。 这样做的目的是减少几个人在同一文件中工作但可以在同一分支中一起工作的机会。

我认为一些常用的git实践将总是有帮助的。 其中一些正在频繁提交，经常从主服务器获取，并解决了小的合并冲突（如果有的话）。

以前很难解决项目中的所有冲突。 但是，几乎每个IDE都与IDE一起提供解决冲突的工具，以便我们可以直观地检查和合并那些冲突的代码。 我认为，采用常见的git实践以及标准的项目结构可以大大减少合并冲突。 除此之外，将master合并到feature分支中是在提交拉取请求之前进行处理的一种干净方法。