logo标签列表

源代码控制 - 每个产品是否需要单独的分支？

svnversion-controltfsbranch
6
假设你有四个产品，每个产品都有自己的发布计划。每个产品有50%的共享代码（所有产品都具有的通用功能）和50%的特定于产品的代码。
对于每个产品，您是否需要单独的源代码控制分支？应该始终在四个产品分支中之一开发共同功能，并稍后合并到其他产品中吗？
典型情况：产品A将在下个月发布，需要核心（共享的）增强1，产品B将在四个月后发布，需要核心（共享的）增强2（需要三个月时间来完成）。
澄清一下，代碼隔離是必不可少的。我不想對於2011年發布的產品B做任何更改，導致明天發布的產品A出現問題。然而，我也不想分叉共用代碼並永遠維護兩個獨立的副本，共用代碼需要保持共用。當一個產品得到“最新”的共用代碼時，它需要再次進行測試才能發布。基於這些信息，應如何建立和維護分支？ - monibius
@Ben Breen - 给出你的澄清后，我仍然建议使用svn:externals。产品A可能会更改核心代码，但是您可以根据产品B的发布计划控制这些更改何时返回到/core/trunk。如果您只是为了产品A而对核心进行更改，那么也许该代码不应该在核心中。 - Terry G Lorber
8个回答
3
我将共享的代码放在它自己的产品文件夹中。然后使用svn:externals在其他产品之间共享代码。处理分支和合并略有些痛苦，但这比在存储库中拥有四份共享代码要好。类似于以下内容（将trunk替换为/branches/RB-1.0.0或/tags/REL-1.0.0以进行发布分支和标记版本）：
/core/trunk
/product_a/trunk
  /core (svn:externals 'core /core/trunk')
/product_b/trunk
  /core (svn:externals 'core /core/trunk')
/product_c/trunk
  /core (svn:externals 'core /core/trunk')
/product_d/trunk
  /core (svn:externals 'core /core/trunk')
<更新0>: 请注意，/product_a/tags/REL-1.0.0 可能使用 /core/tags/REL-1.0.0，而/product_b/tags/REL-1.0.0可能使用 /core/tags/REL-1.1.0。
但是如果你即将发布一个产品，然后检查共享代码中的更改却破坏了它怎么办？ - monibius
@Ben Breen - 产品A的发布分支应该使用核心的发布分支。不要破坏发布分支。在此期间，产品B、C、D的主干将使用核心主干，直到它们准备好发布，并制作新的发布分支以发布产品和核心。 - Terry G Lorber
2

常见功能可以在一个独立的平台分支中开发，每个产品都有自己的分支用于特定于该产品的开发。

在我看来，这并没有回答问题：它是关于各个分支何时以及如何交互的问题。 - ChrisW
1

这并不是对你问题的直接回答，因为我不能百分之百确定是否有一个“一刀切”的答案可以给出。但是Jeff写了一篇关于分支的优秀博客文章。

我理解这个问题是关于共享代码，而不是分支和合并。 - Terry G Lorber
1

这是我读过的关于分支最好的文章之一：面对敏捷开发、极限编程、团队协作和并行发布的分支和合并

我认为我会避免将两个项目的分支（因此也是日程安排）耦合在一起。因此，除了单个分支以外，你正在编辑共同功能并编辑多个产品，也许以下两个选择之一：

1）独立开发共同功能

  • 分离共同功能
  • 添加到其中
  • 进行单元测试
  • 提交回主干
  • 将其作为产品的特定分支（主干）使用并用于产品

2）与一个产品共同开发共同功能

  • 创建一个产品分支
  • 在产品分支中，除了产品特定组件外，还向共同库添加新功能
  • 对其进行单元测试和系统测试并将其提交回主干
  • 将新主干的分支用于在其他产品中使用新提交的共同功能。
1

在你的代码库中，将分支建立在最高可能的位置。也就是说，它应该包含所有项目、共享模块的代码，以及文档、构建脚本、安装程序等等。为什么呢？因为这样做没有任何坏处！在目前所提到的所有系统（SVN、TFS、Perforce、Git）中，创建分支都非常容易。

在使用“路径空间”分支（TFS、Perforce）的系统中，这种策略尤其重要。否则，在不同人的工作区之间生成一致的完整产品套件构建将成为一个维护噩梦。

一旦你实践了这个策略，你就可以在给定的分支中自由地修改代码库的任意部分。你总是可以进行完整的构建来验证集成问题；在任何一组分支之间合并任何组件的选项始终对你开放。但是，SDLC策略的问题是完全正交的。你可以按特性、团队、发布版本或以上任意组合进行分支；你可以根据自己的喜好定义前向/反向集成标准。每个分支恰好是超集的事实在许多策略中都是有利的，只要你的工具能够胜任，这绝不会成为一个缺点。

选择一种策略是个人问题，这取决于许多因素。其他人已经提出了一些著名的文档来帮助你做决定。我认为Microsoft 的 TFS 指南的最新修订版是最好的之一。

确实。如果有人能提出符合要求的明智策略，那就太好了。我一直想知道按特性进行分支是否是良好的实践，或者将一个概念推向疯狂的极端是否可行。 - monibius
我完全同意你所说的分支位置。在我看来，困难的问题是何时分支，有多少个分支，每个分支中有哪些类型的更改（即每个分支的目的），以及如何（例如按什么顺序）更新和/合并分支/更改。 - ChrisW
1
Ben：根据你目前所说的，我建议每个产品至少有1个分支。如果需要隔离开发与测试环境，或者团队非常庞大，则需要更多分支。 - Richard Berg
0
把它们都放在一个分支里。您希望在开发时知道A产品的更改是否会破坏B产品。这比在发现ProductB必须重写另外3个依赖项的公共代码库一半时陷入合并混乱要好得多。

编辑：澄清一下，我的意思是它们应该共享一个开发分支。我建议单独使用生产分支来表示正在生产中的代码，并且如果您定期进行错误修复发布，则使用维护分支。

1
我不同意：因为这需要你在提交包含对两个产品更改的单个分支之前，完成对产品A和产品B的更改。相反，您可能希望在另一个产品完成之前提交/发布一个产品，这意味着有多个分支。 - ChrisW
那里的权衡是，你的项目之间有更大的分离，这可能会（并且历史上确实如此）在尝试合并它们时导致一个非常混乱的局面。 - Andy_Vulhop
0

我们有一个类似的情况。我们有用于记录、数据访问和安全性的公共库，但这些库被用于多个项目。我们所做的是为每个产品创建一个单独的分支集，并使用 SVN externals 来链接到公共库。因此，所有项目都拥有独立的分支，而公共库则在所有项目中维护一个“共享”分支。

这样，我们可以确保所有产品都构建在最新版本的公共库上，同时也能够独立地维护项目。

0

我们使用git将一系列具有共同基础和大量自定义代码的网站构建为一系列分支。

主分支包含核心代码，而主分支的每个分支都是核心的特定定制。在对核心进行更改时，很容易将它们推送到分支中，同时保持每个自定义版本隔离。

18个网站，7人团队的12个月+项目，目前仍然掌控得很好！

喜欢它 - 它提供了真正的代码隔离。但是为什么把核心代码放在一个单独的分支中呢？难道你不想在某个地方看到它的运用，因此必须将其开发成一个产品吗？ - monibius
不，核心不是生产产品，只是定制应用程序的基础。这并不是该方法的限制，而仅仅是项目的一个方面。没有理由不能将主分支作为可发布的产品。 - Codebeef
实际上我意识到这对我们不起作用。我们可能会在本月发布产品A时得到一个要求，需要核心功能增强1。四个月后发布的产品B需要核心功能2（需要三个月才能完成）。 - monibius
2
这就是功能分支发挥作用的地方 - 每个功能也都有自己的(临时)分支，只有在完成后核心和产品分支才会收到更改。这意味着开发人员永远不会因为半完成一个功能而破坏构建。 - Codebeef
一个功能是“用户故事”吗？还是有区别的？ - monibius
其实并没有什么区别。如果我正在进行任何工作单元，我总是在本地创建一个分支（即不在远程存储库上），然后在其中工作。一旦我满意它已经完成并且可以工作，我就会将这些更改推回主/产品分支。这样，如果我需要修复中断我的功能进度的错误，我只需切换回产品分支并进行修复，然后将更改拉入我的功能分支并继续。在任何时候，我都不会将半成品的工作推送到产品分支。 - Codebeef
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接