每个小变化都需要创建一个分支吗？

Question

每个小变化都需要创建一个分支吗？

18

我们有一个客户（有一个客户，有一个客户），他通过对PHP代码库的更改请求让我们发疯。我们最初的反应是在SVN的主干中工作，但客户经常要求将某些更改立即推送到生产服务器。另一方面，其他更改突然降低优先级，这些更改最初与其他更改分组（看起来是这样）。

我们正在考虑为每个更改请求使用一个分支。这疯狂吗？还有什么其他解决方案？

谢谢！

编辑：这是一个非常难选择正确答案的问题。感谢大家的出色回答。

编辑：我知道我选择的最佳答案并不特别受欢迎。我也想找到一个技术解决方案来解决这个问题。但现在我认为，如果客户需要部署可以以模块化方式部署的功能软件...这个问题就不应该通过我们使用版本控制系统来解决。它必须被设计到软件中。

编辑：现在已经快一个月了，我的同事/客户已经说服我，多个分支是正确的方法。这不仅仅是因为客户的疯狂，而且基于我们需要能够确定某个功能是否“准备就绪”或“需要更多工作”等需求。我没有SVN，但我们使用从分支创建到头版本的建议进行合并。

此外，使用这个系统，我们在某个时候会将所有分支合并，并将其成为新的QA，然后是生产版本。然后我们从那个版本创建新的分支。

最后编辑（也许）：几个月后，这个系统对我们仍然有效。我们为每个问题创建一个分支，很少出现问题。另一方面，我们确实尝试保持不同人员所处理的内容分开...

两年后：我们现在使用GIT，现在这个系统实际上相当合理。

- Daniel Rosenstark

现在有Git不就是为了解决这个问题吗？ - Quintin Par

@Quintin Par，无论您使用Git（我们现在正在使用）还是SVN（我们以前使用），问题都是相同的。问题是如何为团队/客户组织分支。 - Dan Rosenstark

1

无论您是否有更改请求或票证，或者您只是在家中工作自己的项目，为每个小更改创建分支都是将提交每个小更改（在分支中）和仅提交（合并）工作代码（在主干中）的绝佳方式。此外，这两种模式的结合可以保持主干日志的清洁，但提供了分支日志的详细信息。 - clacke

@clacke 没错，完全同意（现在） - Dan Rosenstark

11个回答

10

创建一个分支用于客户现有版本，创建一个分支用于新开发以及创建一个分支用于进行持续的更改。

在你没有被任务淹没的时候，请在新开发分支上工作。

当你正在修复那些让你发疯的问题时，请在持续更改分支上工作。当你完成修复时，请将其合并到“现有”分支和“新开发”分支中。

这样，您的客户发布版本就在自己的世界中，您的新开发将继续进行（可以随时合并），而您的维护也会得到记录。

我们在新开发分支上工作，然后每次决定进行补丁时，我们都会从主干创建一个分支，然后将该补丁发送给Q / A测试。如果反复多次，我们就在该分支上工作以解决这些问题，并在必要时将其合并回主干以确保一切同步。如果某个问题在很久之后才需要解决，我们总是可以在该分支上进行修复，然后再将其合并到主干中。

- Mat Nadrofsky

我非常喜欢那个答案。我很好奇其他人会想出什么。谢谢！ - Dan Rosenstark

太好了。很高兴能帮助你。总是很好得到许多回应，找出对你最有效的方法！ - Mat Nadrofsky

精炼/提醒: 标签使得记住修订版本号变得不再重要，所以请给每次向主要开发分支合并打上标签。同样地，请对版本发布也打上标签。此外，有了这种结构，您可以将“实时”版本保留在主干上 - 毕竟，“trunk”只是一个约定。 - Ken Gentle

@ Ken：非常正确。我应该提到这一点！ - Mat Nadrofsky

6

线程发起人所解释的情况是一个特性分支模式的例子：http://svnbook.red-bean.com/en/1.5/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.feature 当您需要保持主要开发线（主干）稳定，同时需要开发许多可能会破坏主要线的功能时，它们非常有用。

缺点是您必须使各个分支与主干同步：在为功能A创建分支进行开发时，功能B的分支可能已经达到稳定状态并被关闭并合并到主干中：在这种情况下，您必须将来自主干的B分支引入的更改合并到A分支中。因此，经常将分支与主干合并是一个好习惯，以避免在分支生命周期结束时出现大量冲突需要跟踪和解决的问题。

- Davide Gualano

谢谢Davide，你是第一个发现我怀疑的事情的人。合并（包括使用SVN和其他工具）并不容易也不愉快。 - Dan Rosenstark

有时候合并是个头疼的问题，但有时候也不是：这很大程度上取决于变更的大小以及受变更影响的代码部分。通常情况下，Subversion可以自动正确地处理这些变更，但并非总是那么容易。 - Davide Gualano

我想补充一下这个答案，永远不要在主干上进行开发。这可以确保主干始终稳定。 - fglez

3

每个变更请求都创建一个分支听起来有些过度，也许以后会带来一些麻烦。试着将变更请求分组到逻辑区域中，这样你就可以看到一组特定的变更对应用程序产生了逻辑相关的影响。为这些创建分支。

然而，我认为真正的答案是要解决客户端的问题。你需要通过合同明确表示这些随意的变更请求将花费他们的金钱，并且可能会减慢项目进程。如果这种情况持续下去，你的svn仓库将是该项目中最不麻烦的方面。

- Vincent Ramdhanie

1

它会花费他们的金钱和减缓他们的速度。我为什么要修复它们？为了我的心理健康吗？这就是为什么我拥有技术，当这不够时，我还有禅修。 - Dan Rosenstark

我收回之前的说法。现在我认为你可能是对的：如果你想要构建一个模块化的软件系统，你不应该从你的版本控制系统开始。感谢你的回答。 - Dan Rosenstark

虽然我将其留作最佳答案（这是什么意思？），但我们实际上已经开始使用分支来进行所有更改，结果非常不错。 - Dan Rosenstark

我认为分支的数量可能是一个项目或团队决策，而不是可以广泛陈述的事情。在我们的团队中，我发现太多的分支实际上可能会导致更多的问题...所以我们试图限制它。但我并不惊讶你发现很多分支对你来说运作良好。 - Vincent Ramdhanie

3

对于这个问题，每个变更请求都创建一个分支，并且相应地增加客户的管理成本是一种不错的方法。

这将会在时间上、资源上等方面花费更多，可能会影响到其他功能的开发，但对于许多无关的变更或项目特性被搁置或取消的情况下，这很可能是更好的方法之一。

这实际上与SCM系统无关，但Subversion肯定可以满足所需。

- Ken G

这也是我们的想法，但我认为其他一些出现的答案更有趣，特别是Mat Nadrofsky提出的结构。我同意特定的SCM并不重要。 - Dan Rosenstark

现在，很久以后，我认为你是对的...但这是主观的，我想。 - Dan Rosenstark

2

每个经过测试并工作的更改都要分支。
每个版本发布都要打标签。
在主干上进行开发。
重复以上步骤。

:)

- Adam

在Subversion下，它们基本上是相同的 - 主要区别在于它们如何被视为（特定时间的快照 vs. 开发分支）。 - Tim Whitcomb

2

为每个发布版本创建一个分支。将尽可能多的更改合并到单个发布版本中 - 拥有更多的分支通常是好的，你可以在大多数情况下轻松地将它们合并，但拆分它们则需要更多技巧。

为每个发布版本创建一个分支意味着你也有一个当前正在生产环境上使用的分支（或者当合并后等待实际部署时即将发布的分支）。

这就是我们目前所做的。

- MarkR

1

在我的工作场所，我们有以下系统：

稳定分支：这是经过测试和验证的稳定代码所在的地方。
维护分支：这是修复稳定分支中错误的地方。当事情被验证可以工作时，它会被合并到稳定分支。
项目特定分支：我们产品中的每个子项目都有一个分支。在一年中的指定时间，所有要包含在今年发布的项目都会合并到“发布分支”中。这样所有的合并和其他操作不会在发布前一周完成。
发布分支：这是在子项目合并后当前版本的混乱开发发生的地方。发布完成后与稳定分支合并。

- Nailer

谢谢。有趣的系统。如果你不介意的话，你们有多少开发人员？ - Dan Rosenstark

全球约有80名员工，其中包括产品专家和领域专家。大约一半是开发人员。 - Nailer

太棒了，感谢您的回复。如果 Stack Overflow 能告诉我您已经回复就好了... - Dan Rosenstark

1

使用Git时，我会为每个小更改创建一个分支，我非常喜欢它！

- hasen

0

当估计工时超过8小时时，使用分支。

- Ludwig Wensauer

为什么是8呢？虽然我喜欢定量规则。 - Dan Rosenstark

1

8 真的代表“一个工作日”吗？也许我们应该定义一个全局常量？ - Dan Rosenstark

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- ypnos · Accepted Answer

也许Subversion并不是最适合此工作的工具。虽然在SVN中创建所有这些分支很容易，但重新合并它们可能会变得耗时且痛苦。

如果你看一下GIT而不是SVN，你会发现一个更强大的版本控制系统，它在合并方面更加出色。除此之外，它还具有“cherry picking”这个特定功能。也就是说，单个提交可以轻松地从一个开发树中“挑选”并添加到另一个（即实时分支）。此外，在GIT中将多个提交合并成一个单一提交也很容易和方便（甚至可以从另一个树添加到特定提交）。

因此，建立单一功能提交，然后进行挑选可能是您的解决方案。