1. 首页
  2. 问答
  3. 分支策略

分支策略

2008-08-29 160 views
73

我工作的公司开始遇到与他们当前的分支模型有关的问题，我想知道社区接触到了哪些不同类型的分支策略？分支策略

对于不同的情况有没有什么好的方法？贵公司使用什么？他们的优点和缺点是什么？

来源

2008-08-29 Craig H

+1

阅读本经典：http://oreilly.com/catalog/practicalperforce/chapter/ch07.pdf – zvolkov 2009-04-15 23:41:54

+0

@casperOne这可能是最有趣的方式来处理一个链接的答案标志我见过 – gnat 2012-02-24 20:48:18

+1

@gnat来部分包裹与答案上的国旗处理。 =） – casperOne 2012-02-24 21:13:14

回答

20

我强烈鼓励阅读埃里克库的意见对此事：

Chapter 7: Branches

我，像埃里克，喜欢的分支，他谈到了“文件夹”的风格。

来源

2008-08-29 18:41:04

+5

埃里克说： “简单的变化，正如我在我的”埃迪“情景中提到的，不要为每个错误修复或功能分支。” 但是随着新的SCMs的出现，这不再是事实。 SVN的人们常常说，直到他们实现了正确的分支......而GIT的人将永远不会这么说...... 但通常情况下，某个版本控制背后的人会说他们不能做的事情是不值得的......： - （ – pablo 2009-04-27 22:46:54

0

这将取决于您正在使用的版本控制系统。每个VCS都有不同的分支方法。

您使用哪个VSC？

来源

2008-08-29 18:42:15

2

我们目前有一个分支机构正在进行维护，其中一个分支机构为“新举措”，意思是“将来某个时候出来的东西;我们不确定何时”。我们偶尔还会有两个维护分支机构：一个为目前正在生产的产品和一个仍在质量保证中的产品提供修复。

我们看到的主要优势是能够更快速地对用户请求和紧急情况做出反应。我们可以对正在生产的分支进行修复并释放它，而不会释放任何可能已经检入的额外内容。

主要缺点是我们最终在分支之间进行了大量合并，这增加了分支之间的合并有可能错过或错误地合并。到目前为止，这并不是一个问题，但它绝对是要记住的。

在我们制定这项政策之前，我们通常在干线中做了所有的开发工作，并且只在我们发布代码时进行分支。然后，我们根据需要对该分支进行了修复。这很简单，但不够灵活。

来源

2008-08-29 18:42:37

1

我们在工作中遵循的理念是保持树干处于可随时推动的状态，而不会对网站造成严重伤害。这并不是说干线总是处于完美的状态。当然会有错误。但重要的是永远不要让它大打折扣。

如果您有要添加的功能，分支。设计更改，分支。我曾经想过很多次，“噢，我可以在后备箱里做这件事，不会花费那么长时间”，然后5个小时后，当我无法弄清楚那个破坏我的东西的错误时真的希望我有分支。

当您保持行李箱干净时，您可以让机会快速应用并推出错误修复程序。您不必担心您方便分支的破解代码。

来源

2008-08-29 18:52:40

0

对于Subversion，我同意Ryan Duffield的评论。他提到的这一章提供了一个关于使用哪个系统的良好分析。

我问的原因是，Perforce提供了一种完全不同的方式来从SVN或CVS创建分支。另外，还有所有的DVCS都有自己的分支哲学。您的分支策略将由您正在使用的工具决定。

仅供参考，Svnmerge.py是一个工具，用于协助合并SVN中的分支。只要你经常使用它（每10-30次），它就会工作得很好，否则工具会变得混乱。

来源

2008-08-29 18:52:44

3

我们在发布准备好进行最终质量检查时进行分支。如果在质量保证过程中发现任何问题，则错误在分支中得到修复，验证并合并到中继。一旦分支通过QA，我们将其标记为发布。该版本的任何修补程序也会对分支进行修改，验证，合并到中继，然后标记为单独的版本。

的文件夹结构应该是这样的（1个QA线，2级修复程序的版本中，与躯干）：

/分支

/REL-1.0

/标签

/REL-1.0

/REL-1.0.1

/REL-1.0.2

/后备箱

来源

2008-08-29 19:02:08

53

这是我在与良好的成功过去使用的方法：

/树干 - 出血边缘。下一个主要版本的代码。可能在任何时候或可能不工作。

/branches/1.0,1.1等代码的稳定维护分支。用于修复错误，稳定新版本。如果维护分支，它应该编译（如果适用）并准备在任何给定时间进行质量保证/运输。如果是稳定分支，它应该编译并且功能完整。不应添加任何新功能，不要重构，也不要执行代码清理。您可以添加前缀来指示稳定分支与维​​护分支。

/branches/cool_feature。用于高度实验性或破坏性工作，可能会或可能不会将其变成后备箱（或维修分部）。没有关于代码编译，工作或其他行为的保证。在合并到主线分支之前应尽可能保持最短时间。

/tags/1.0.1,1.0.2,1.1.3a等等。用于标记已包装的&发货版本。永远不会改变。尽可能多地创建标签，但它们是不可变的。

来源

2008-08-29 19:17:18 jcoby

3

我们使用野生，野生，西方风格的git分支。我们有一些根据惯例定义的着名名称的分支机构，但在我们的案例中，标签实际上对我们来说更重要，以满足我们的企业流程政策要求。

我在下面看到你使用Subversion，所以我想你可能应该看看关于在Subversion Book分支的部分。具体来说，请查看Branch Maintenance和Common Branch Patterns中的“资源库布局”部分。

来源

2008-08-29 19:23:20

7

我们的库看起来像是：

/trunk 
/branches 
/sandbox 
/vendor 
/ccnet

/后备箱是标准的，前沿的发展。我们使用CI，因此必须始终构建并通过测试。

/branches这是我们把'认可'的大变化，也就是我们知道的东西会变成树干，但可能需要一些工作并会破坏CI。我们也在维护版本的工作中，这些维护版本有自己的CI项目。

/沙箱每个开发人员都有自己的沙箱，以及共享的沙箱。这是针对诸如“让我们的产品添加一个LINQ提供程序”类型的任务，当您没有进行真正的工作时所做的任务。它最终可能会进入主干，它可能不会，但它在那里，并在版本控制下。这里没有CI。

/vendor我们编译的项目的标准供应商分支，但它不是我们维护的代码。

/ccnet这是我们的CI标签，只有CI服务器可以在这里写入。后见之明本来会告诉我们将其重新命名为CI，BUILDS等更通用的东西。

来源

2008-09-12 16:56:08

3

我在这里没有看到的替代方案是“分支变革”哲学。

而不是让你的树干“狂野的西部”，如果树干是“当前版本”会怎么样？如果一次只发布一个版本的应用程序（如网站），则此方法可行。当需要新功能或错误修复时，分支会保留该更改。通常这可以将修补程序逐个迁移到单独发行版，并防止您的牛仔编码器无意中添加一个功能以释放您不想要的功能。 （通常这是一个后门 - “仅用于开发/测试”）

本柯林斯的指针在确定哪种风格适合您的情况非常有用。

来源

2008-09-15 17:37:47

2

Jeff Atwood wrote关于此在一个很好的博客文章;该帖子中有一些重要的链接。为积极发展

来源

2008-10-24 10:51:11 spinodal

7
  1. 一个分支（/主或主，根据不同的行话）
  2. 每个维护版本的一个分支 - >将只接收非常小的修正，而所有主要的发展进入/主
  3. 每个新任务的一个分支：创建一个新的分支来处理Bugzilla/Jira/Rally上的每个新条目。经常提交，使用英寸鹅卵石检查自行记录更改，并且只有在完成并经过良好测试后才将其合并回“其父”分支。

看看这个http://codicesoftware.blogspot.com/2010/03/branching-strategies.html一个更好的解释

来源

2009-04-27 22:41:35 pablo

0

不管是哪个分支模式选择，你应该尽量保持你的分支在一个二进制树形式是这样的：

trunk - tags 
    | 
    next 
/\ \ 
bugfix f1 f2 
     / \ \   
     f11 f21 f22
  • 子节点只应与直接父级合并。
  • 试试你最好只合并整个分支与父分支。从不合并分支内的子文件夹。
  • 只要您只合并并从整个分支中挑选，您可以在需要时选择提交。
  • 上图中的下一个分支仅用于说明，您可能不需要它。

来源

2010-03-17 09:27:35

6

的第一件事：KISS（！保持简单愚蠢）

 
/branches 
    /RB-1.0 (*1) 
    /RB-1.1 (*1) 
    /RB-2.0 (*1) 
/tags 
    /REL-1.0 (or whatever your version look like e.g. 1.0.0.123 *2) 
    /REL-1.1 
    /REL-2.0 
/trunk 
    current development with cool new features ;-)

* 1）保持版本维护 - 例如服务包，修补程序，错误修正，其可被合并到主干如果必要和/或需要的话） * 2）major.minor.build.revision拇指

规则：

  1. 的标签的文件夹不必在发布分支被检查出
  2. 只有很少的编码（使合并更简单） - 无码清理等
  3. 从未在标签文件夹编码
  4. 不要把具体版本信息为源文件。使用占位符或0.0.0.0，其构建机制将由您正在编译的版本号替换
  5. 永远不要将第三方库放入源代码管理中（也没有人会将STL，MFC等库添加到SVN中; - ））
  6. 只有提交，编译
  7. 不想使用环境变量，而不是硬编码路径（绝对和相对路径）

--hfrmobile

来源

2011-01-05 14:48:30 hfrmobile

2

蚋已在各个位写this excellent break down代码你可以在branc上找到的建议兴战略。

这里没有一个分支策略，它就是适用于：

  • 你的团队规模
  • 你的产品和生命周期阶段
  • 您正在使用的技术（网络，嵌入式的Windows应用程序）
  • 您的源代码管理，例如Git，TFS，Hg

Jeff Atwood的post打破了很多可能性。另一个要补充的是促销的概念（来自Ryan Duffield的链接）。在这个设置中你有一个开发分支，测试bracnh和发布分支。直到它到达发布分支并进行部署之前，您都会提升代码。

来源

2011-10-19 11:10:26

相关问题

 相关问题