频繁的复杂合并冲突是问题的征兆吗？

在我们的团队中，我们使用Git作为源代码控制。我们有几个几乎独立的代码区域，但是有一些重叠。最近，我们一直在讨论使用源代码管理的工作流程和方法。当我使用功能分支工作流进行升级时，出现的一个抱怨是人们经常遇到复杂的合并冲突，而他们无法正确解决。复杂地说，我的意思是“解决方法不明显”。鉴于此，正在更加积极地使用其他工作流程，例如基于“拉底”的工作流程。

作为功​​能分支方法的倡导者，我并没有真正抱怨过。是的，您必须保持本地要素从master或任何地方分支最新，但这是我所看到的唯一真正的问题。我在想，如果您的合并总是很复杂并且可能会产生辅助影响，那么这更多是团队合作问题，而不是Git问题。

我认为正确吗？复杂的合并冲突是好事还是坏事的征兆？

问题并非不可能是您的代码。如果您的代码库在模块之间有很多相互关系，那么每次更改都会到处都是卷须，并且每个开发人员都会与其他人的代码进行交互，这将是一场噩梦。

我倾向于认为您会首先以其他方式注意到这一点，但是您可能已经习惯了它，以至于看不到它。

我已经习惯了“提取-重新推送”工作流程。这实际上是您的教程中描述的第一个，最原始的工作流程以下是优点：

• 真正的持续集成
• 早期冲突管理-在编写和测试代码之后
• 快速反应-“嘿，鲍勃，您写的三次插值给出了有趣的结果，您能在我吃午饭时看一下吗？
• 没有合并提交-清除时间线，就好像一位开发人员写了everithyng

现在，关于复杂的合并冲突。我不了解人们如何经历频繁和复杂的合并。长时间不进行重新定购/樱桃采摘，并在该功能上工作了一个月，便导致了问题的复杂化。

我个人更喜欢处理频繁，容易的合并（实际上是变基）冲突，而不是罕见的，无所不包的合并恐怖。

对于人类必须解决的那些固有冲突（例如，两个开发人员更改同一行代码），合并和重新设置应该引起完全相同的冲突。对于其他冲突，合并实际上通常更干净，因为您并没有在所有位置更改提交的SHA-1。我不确定您如何进入合并导致的冲突而不是重新部署的冲突的状态，但这肯定表明某些人的工作流程混乱了，他们可能需要更多有关git工作原理的培训。他们在进行本地基准调整时会删除其他人的合并提交吗？

pull-rebase方法的优点和缺点是，它与很多人习惯的集中式工作流程非常相似。您无需了解分支即可使用它。

无论如何，如果您无法让其他人登录，则仅在本地执行功能分支工作流是完全可行的。

我正在从事的项目有时会遇到这类问题，它似乎是由以下两个因素造成的：

• 我们使用的是Visual Studio，像Visual Studio .sln这样的文件只是XML文档（对文本合并的响应不佳），里面装满了Guid（Git无法比我们其他人更了解），并且很容易严重合并并导致文件丢失。
• 有些人正在研究代码的相似区域，以便在类中彼此紧挨着推送更改。尽管在这种情况下是不可避免的，但是对于任何源代码控制系统而言，这种类型的配置都将非常艰巨。即使您在团队中进行了很好的沟通，有时人们也不会意识到他们正在碰到彼此的代码，并且会发生冲突。

我对语义合并可以帮助解决其中一些问题的潜力感兴趣，但是显然，这只有在您使用的语言可以解析的情况下才有用，并且当我使用该语言时，我还没有遇到任何重大挑战我正在使用它，所以我不能保证它的有效性。

除非开发人员正在修改历史提交（而非纯合并），否则功能工作流类型git模型中的冲突是紧密耦合的代码库（/全新代码库）或重叠的功能分配的标志。

您有一个主（主）分支，每个人都在其功能分支中工作。

功能分支的工作可能需要数小时到数月的时间。

时不时有人会将其变更集反向合并回主分支。您的团队负责人需要确保一次只有一个人进行反向合并。完成此操作后，您需要将合并从Main分支转发到功能分支。一旦每个人都进行向前合并，就可以允许另一个人将其反向合并到主分支中。否则，太多的更改将被反向合并，并且您在正向合并中将有大量的合并冲突。

为了澄清术语，“反向合并”是指从特征分支合并到主分支，而“正向合并”是指从主分支合并到特征分支。根据我以前的经验，与正向合并相比，您可能会在反向合并中看到更多合并冲突。

有两件事可能会有所帮助：第一，避免使用任何自行进行更改的工具。两位开发人员使用不同的选项卡设置是灾难的根源。第二，在不同的位置进行更改。例如，如果三个开发人员在同一文件的末尾添加代码，就会遇到问题-如果他们在不同位置添加代码会更好。