分支策略

Question

我工作的公司开始遇到他们目前的分支模型的问题,我想知道社区有哪些不同的分支策略？

对于不同情况,有什么好的吗？贵公司使用什么？它们的优点和缺点是什么？

Answer 1

这是我过去使用的方法,取得了很好的成功:

/ trunk - 流血的边缘.下一个主要版本的代码.在任何给定时间可能会或可能不会工作.

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

/支链/ cool_feature.用于高度实验性或破坏性的工作,可能会或可能不会进入主干(或维护分支).无法保证代码编译,工作或以其他方式表现得非常好.在合并到主线分支之前应该尽可能持续最短时间.

/tags/1.0.1,1.0.2,1.1.3a等用于标记打包和发布的版本.永远不会改变.制作任意数量的标签,但它们是不可变的.

Answer 2

我非常鼓励阅读Eric Sink对此事的看法:

第7章:分支机构

我和Eric一样,更喜欢他谈到的"文件夹"式分支.

Answer 3

对于分支模式的母亲,请参阅Brad Appleton的流线:并行软件开发的分支模式.这是繁重的责任,但我没有看到任何超越它的分支知识的广度和深度.

Answer 4

我们的存储库如下:

/trunk
/branches
/sandbox
/vendor
/ccnet

/ trunk是你的标准,前沿发展.我们使用CI,因此必须始终构建并通过测试.

/分支 这是我们放置"制裁"的大变化的地方,即我们知道的东西会变成主干但可能需要一些工作并且会破坏CI.此外,我们在维护版本上工作,这些版本都有自己的CI项目.

/ sandbox 每个开发人员都有自己的沙箱,还有一个共享的沙箱.这是为了"让我们的产品添加一个LINQ提供程序"这类任务,当你不做你真正的工作时,你会这样做.它可能最终进入主干,它可能不会,但它存在并受版本控制.这里没有CI.

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

/ ccnet 这是我们的CI标签,只有CI服务器可以在这里写.Hindsight会告诉我们将其重命名为更通用的内容,例如CI,BUILDS等.

Answer 5

1. 一个用于主动开发的分支(/ main或master,取决于行话)
2. 每个维护版本的一个分支 - >它只会收到很小的修复,而所有主要的开发都会转到/ main
3. 每个新任务的一个分支:创建一个新分支,以处理Bugzilla/Jira/Rally上的每个新条目.经常提交,使用英寸卵石签入自行记录更改,并在完成并经过充分测试后将其合并回"父"分支.

请查看此http://codicesoftware.blogspot.com/2010/03/branching-strategies.html以获得更好的解释

Answer 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. 不需要签出Tags文件夹
2. 在发布分支中只有少数编码(使合并更简单) - 无需代码清理等.
3. 永远不要在标签文件夹中编码
4. 切勿将具体版本信息放入源文件中.使用占位符或0.0.0.0,构建机制将替换为您正在构建的版本号
5. 永远不要将第三方库放入源代码控制中(也没有人会将STL,MFC等库添加到SVN ;-))
6. 只提交编译的代码
7. 更喜欢使用环境变量而不是硬编码路径(绝对路径和相对路径)

--hfrmobile

Answer 7

目前，我们有一个用于持续维护的分支，一个用于“新举措”的分支，这意味着“将来某个时候会出现的东西；我们不确定什么时候”。我们偶尔也会有两个维护分支：一个为当前生产中的内容提供修复，另一个仍在质量检查中。

我们看到的主要优点是能够更快地响应用户请求和紧急情况。我们可以对生产中的分支进行修复并发布它，而无需释放任何可能已签入的额外内容。

主要缺点是我们最终会在分支之间进行大量合并，这增加了遗漏或错误合并某些内容的可能性。到目前为止，这还不是问题，但这绝对是需要记住的事情。

在我们制定这个政策之前，我们通常在主干中进行所有开发，只有在发布代码时才进行分支。然后我们根据需要对该分支进行修复。它更简单，但不那么灵活。