分支是否会被认为是一种不好的做法？

Question

可能重复: 分支还是不分支？

同事反对支行.我一直都在用分支。我把团队放到了一个基本的3分支系统上。我创建了自己的功能分支。他说，同事往往有好的想法，遵循最好的做法，我倾向于在许多这样的事情上同意他的观点。除了这个。

我读过的成功的软件商店:微软，谷歌，fogcreek都使用分支。我的同事认为，由于我们商店的经营方式(医疗领域)，分支会引起问题。相反，他说我们应该创建许多小项目的(*.csproj文件)，而不是同时处理相同的代码。

我同意，我们对合并有意见。我认为，造成这些问题的根本原因是缺乏团队沟通，以及缺乏关于如何正确使用我们的源代码控制系统以充分发挥作用(TFS)的知识。我认为他的方法是在Silo的编程和DLL管理噩梦。

在某些情况下，分支是个坏主意吗？我说错了吗？

Answer 1

这个问题是非常笼统的--我可以肯定地说，在某些情况下，X是个坏主意，不管X通常有多好。

当良好的源代码管理和合并工具还不存在的时候，你的同事会坚持一种观点，这在当时是必要的。他根本不相信合并可以在日常的基础上起作用。

不到5年前，我和一些坚持锁定签出(编辑前必须签出，一次只能签出一个文件)的人一起工作，因为他们不明白合并是可能的，而且工作得很好。

问题是:为什么你的同事不相信合并？自从很多年前我第一次在CVS上看到它起作用以来，我就一直相信它。

我的猜测是，在你的操作中有一些东西会导致合并问题，而你的同事看不出这是可能的，因为你的团队有一些操作上的问题。在你搞清楚那是什么之前，你永远不会说服他的。

Answer 2

我个人的经验是，在这种情况下，培训会有所帮助。

我对同事也有同样的问题(对SVN)。在培训了我的同事之后，一个项目组(我不是其中的一员)只在分支上发展，之后就再也没有在主干上发展过了。

在训练中最重要的是合并(以及其间的冲突)是正常的，也不例外。如果你的同事对合并和冲突失去了恐惧(因为这是正常的)，那么过了一段时间，情况就会明朗了。

Answer 3

更多的分支意味着更多的复杂性。想象你的软件成长，团队成长，时间流逝.我认为主要的问题是处理合并和冲突，如果分支机构开始太分散，人们在这些问题上的工作是平行的。

愚蠢的例子:我们有两个大分支，在重叠区域中有变化，而一个家伙有一个超级聪明的想法，把所有的选项卡都更改为主干...arrrrghh ...the合并上的空格，这是一场噩梦。实际上，合并工具甚至没有正确地处理它，因此，最终，我没有“合并”数千行逐条手工。

另外，随着时间的推移，你必须记录下什么是什么，哪些仍然是活跃的，哪些不是，如果某个分支保持太长时间不活动，就很难合并，或者有人会在解决冲突时忘记一个迷你修复，等等。

我想，最终，这都是一个关于正确平衡的问题。当你需要的时候做一个分支，但不要“只是为了好玩”。与SVN相比，我更倾向于使用Git或Mercurial创建分支，它们在处理分支时更容易和更灵活，而SVN对我来说已经有好几次了。因此，我想这取决于您使用的是什么，...but较少的分支通常会使生活变得更容易。