我们在版本控制中分支可能会遇到什么问题？

Question

您能否就软件团队在版本控制环境中分支可能遇到的问题提出一篇文章，一本书或一份会议论文？我们正在为我们的一个赞助商创建摘要，并需要引用可靠的信息来源。到目前为止，我已经通过Chris Birmele和Eric Sink找到了简短的评论。

提前致谢！

PS。 Appleton等人的文章Branching Patterns for Parallel Software Development。 al看起来很基本，但相当古老。

Answer 1

如Martin Fowler's Bliki中所述，FeatureBranch可能会遇到语义冲突的问题。

  

我更担心的问题是语义冲突   一个简单的例子是，如果Plum教授改变了牧师格林代码所称的方法的名称   重构工具允许您安全地重命名方法，但仅限于您的代码库。因此，如果G1-6包含调用foo的新代码，Plum教授无法告诉他的代码库，因为他没有。你只能找到大合并。

     

函数重命名是一个相对明显的语义冲突案例。在实践中，它们可以更加微妙。测试是发现它们的关键，但合并的代码越多，就越有可能发生冲突，修复它们的难度就越大。
  冲突的风险，特别是语义冲突，使大合并变得可怕。

请参阅this SO question中的语义冲突示例。

---

考虑到这一点后，您还需要区分CVCS and DVCS（集中式与分布式VCS），因为DVCS会为分支带来正交维度：“publication”（推/拉）往/来自远程存储库，这意味着您可以在“相同”分支上工作，同时仍处于完全隔离状态，因为您正在使用本地克隆存储库。）
像SVN这样的CVCS有own issues和merging branches，DVCS应该非常擅长。

另请参阅“When should you branch?”

Answer 2

查看Hg Init - 它详细解释了为什么在某些情况下分支是非常有问题的，以及如何缓解这个问题。关键点在于分支根本不是问题，但在不同的分支上合并回来可能会耗费大量时间。

Answer 3

对不起，我找不到对实际陈述的引用，但我记得Larry McVoy说的是“你永远不希望分支成倍增加，你总是希望将分支重新合并在一起”。您的分支机构越长越好，一个分支机构的更改与另一个分支机构的更改冲突的可能性就越大。功能分支是你的朋友，但我建议经常提取更改，以便及时了解“主干”或“上游”的道德等同变化，并确保尽快将分支合并回“主干”或“上游”他们的需要得到了满足。

也许更简洁一点，我总是发现在创建分支之前定义分支的生命周期很有用。知道你为什么要创建一个分支，它将存活多久，何时你决定将它合并或扔掉它。