您能否推荐一篇文章、一本书或一篇会议论文，介绍软件团队在版本控制环境中分支时可能遇到的问题？我们正在为我们的一位赞助商创建一份摘要，并且需要引用可靠的信息来源。到目前为止，我已经找到 Chris Birmele 和埃里克·辛克。
提前致谢！
附： Appleton 等人的文章并行软件开发的分支模式。 al 看起来很基础，但相当古老。
Could you please suggest an article, a book, or a conference paper about possible problems a software team may experience with branching in version control environment? We're creating a summary for one of our sponsors, and need to quote respectable sources of information. So far I've found short reviews by Chris Birmele and Eric Sink.
Thanks in advance!
ps. The article Branching Patterns for Parallel Software Development by Appleton et. al looks fundamental, but rather old.
发布评论
评论（3）
正如 Martin Fowler 的 Bliki 中提到的，FeatureBranch 可能存在语义冲突。
请参阅 这个问题。
考虑到这一点后，您还需要区分 CVCS 和 DVCS（集中式 VCS 与分布式 VCS），因为 DVCS 将为分支带来正交维度：“发布”（向/从远程存储库推送/拉取，这意味着您可以在“同一”分支上工作，同时仍然完全隔离，因为您正在处理本地克隆存储库）。
像 SVN 这样的 CVCS 有其自己的问题 ://stackoverflow.com/questions/2471606/how-and-or-why-is-merging-in-git-better-than-in-svn/2472251#2472251">合并分支，DVCS是应该是非常擅长的。
另请参阅“何时应该分支？”
As mention in Martin Fowler's Bliki, FeatureBranch can have their issue with semantic conflicts.
See example of semantic conflicts in this SO question.
Once that is taken into account, you need also to differentiate CVCS and DVCS (Centralized vs. Distributed VCS), as a DVCS will bring an orthogonal dimension to branching: "publication" (push/pull to/from remote repositories, meaning you can work on the "same" branch, while still being in complete isolation because you are working on a local cloned repository).
CVCS like SVN have their own issues with merging branches, which DVCS are supposed to be very good at.
See also "When should you branch?"
查看 Hg Init - 它详细解释了为什么分支在某些情况下会出现很大问题以及如何缓解此问题。关键是分支根本不是问题，但是合并不同分支上的更改可能会消耗大量时间。
Look at Hg Init - it explains in detail why branching is very problematic in certain cases and how to mitigate this problem. The key point is that branching is not a problem at all, but merging back changes on different braches can consume a lot of time.
很抱歉，我找不到对实际声明的引用，但我记得 Larry McVoy 说了一些话“你永远不希望分支倍增，你总是想再次将分支合并在一起”。分支的突出时间越长，其中一个分支的更改与另一个分支的更改发生冲突的可能性就越大。功能分支是你的朋友，但我确实建议经常拉动更改，以跟上“主干”或“上游”的道德等价物的变化，并确保尽快将分支合并回“主干”或“上游”他们的需要得到满足。
也许更简洁地说，我总是发现在创建分支之前定义分支的生命周期很有用。知道你为什么要创建一个分支，它会存在多久，什么时候你会决定合并它或扔掉它。
I'm sorry I cannot find a reference to the actual statement, but I recall Larry McVoy saying something along the lines of "you never want branches to multiply, you always want to merge branches back together again". The longer your branches are outstanding, the more likely it is for changes in one to conflict with changes in another. Feature branches are your friends, but I do recommend pulling changes often enough to keep abreast of changes in the moral equivalent of 'trunk' or 'upstream', and be sure to merge branches back into 'trunk' or 'upstream' as soon as their need is fulfilled.
Perhaps more succinctly, I've always found it useful to define the lifetime of a branch before creating it. Know why you're creating a branch, how long it will survive, when you'll decide to merge it or throw it away.