我工作的公司开始遇到他们目前的分支模型的问题,我想知道社区有哪些不同的分支策略？
对于不同情况,有什么好的吗？贵公司使用什么？它们的优点和缺点是什么？
这是我过去使用的方法,取得了很好的成功:
/ trunk - 流血的边缘.下一个主要版本的代码.在任何给定时间可能会或可能不会工作.
/branches/1.0,1.1等.代码的稳定维护分支.用于修复错误,稳定新版本.如果是维护分支,则应编译(如果适用)并准备好在任何给定时间进行质量保证/运输.如果是稳定分支,它应该编译并且功能完整.不应添加任何新功能,不进行重构,也不需要进行代码清理.您可以添加前置前缀以指示稳定分支与维护分支.
/支链/ cool_feature.用于高度实验性或破坏性的工作,可能会或可能不会进入主干(或维护分支).无法保证代码编译,工作或以其他方式表现得非常好.在合并到主线分支之前应该尽可能持续最短时间.
/tags/1.0.1,1.0.2,1.1.3a等用于标记打包和发布的版本.永远不会改变.制作任意数量的标签,但它们是不可变的.
我非常鼓励阅读Eric Sink对此事的看法:
第7章:分支机构
我和Eric一样,更喜欢他谈到的"文件夹"式分支.
对于分支模式的母亲,请参阅Brad Appleton的流线:并行软件开发的分支模式.这是繁重的责任,但我没有看到任何超越它的分支知识的广度和深度.
我们的存储库如下:
/trunk /branches /sandbox /vendor /ccnet
/ trunk是你的标准,前沿发展.我们使用CI,因此必须始终构建并通过测试.
/分支 这是我们放置"制裁"的大变化的地方,即我们知道的东西会变成主干但可能需要一些工作并且会破坏CI.此外,我们在维护版本上工作,这些版本都有自己的CI项目.
/ sandbox 每个开发人员都有自己的沙箱,还有一个共享的沙箱.这是为了"让我们的产品添加一个LINQ提供程序"这类任务,当你不做你真正的工作时,你会这样做.它可能最终进入主干,它可能不会,但它存在并受版本控制.这里没有CI.
/ vendor 标准供应商分支用于我们编译的项目,但它不是我们维护的代码.
/ ccnet 这是我们的CI标签,只有CI服务器可以在这里写.Hindsight会告诉我们将其重命名为更通用的内容,例如CI,BUILDS等.
一个用于主动开发的分支(/ main或master,取决于行话)
每个维护版本的一个分支 - >它只会收到很小的修复,而所有主要的开发都会转到/ main
每个新任务的一个分支:创建一个新分支,以处理Bugzilla/Jira/Rally上的每个新条目.经常提交,使用英寸卵石签入自行记录更改,并在完成并经过充分测试后将其合并回"父"分支.
请查看此http://codicesoftware.blogspot.com/2010/03/branching-strategies.html以获得更好的解释
第一件事: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
拇指规则:
不需要签出Tags文件夹
在发布分支中只有少数编码(使合并更简单) - 无需代码清理等.
永远不要在标签文件夹中编码
切勿将具体版本信息放入源文件中.使用占位符或0.0.0.0,构建机制将替换为您正在构建的版本号
永远不要将第三方库放入源代码控制中(也没有人会将STL,MFC等库添加到SVN ;-))
只提交编译的代码
更喜欢使用环境变量而不是硬编码路径(绝对路径和相对路径)
--hfrmobile
京公网安备 11010802040832号 | 京ICP备19059560号-6 