分支策略
我工作的公司开始遇到他们当前的分支模型的问题，我想知道社区已经接触到了哪些不同类型的分支策略？
有没有适合不同情况的好方法？ 你们公司用什么？ 他们各有什么优点和缺点？？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
我工作的公司开始遇到他们当前的分支模型的问题，我想知道社区已经接触到了哪些不同类型的分支策略？
有没有适合不同情况的好方法？ 你们公司用什么？ 他们各有什么优点和缺点？？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（12）
我们在工作中遵循的理念是让主干保持在可以随时推动的状态，而不会对场地造成太大的伤害。 这并不是说行李箱永远处于完美状态。 这里面当然会有bug。 但重点是永远、永远不要让它彻底破裂。
如果您有要添加的功能，请分支。 设计变更，分支。 有很多次我想，“哦，我可以在后备箱里做这件事，不会花那么长时间”，然后 5 小时后，当我无法找出破坏事物的错误时，我我真的希望我有分支。
当您保持后备箱清洁时，您就有机会快速应用和推出错误修复。 您不必担心您方便地分支出的损坏的代码。
The philosophy that we follow at work is to keep the trunk in a state where you can push at any time without drastic harm to the site. This is not to say that the trunk will always be in a perfect state. There will of course be bugs in it. But the point is to never, ever leave it broken drastically.
If you have a feature to add, branch. A design change, branch. There have been so many times where I thought, "oh I can just do this in the trunk it isn't going to take that long", and then 5 hours later when I can't figure out the bug that is breaking things I really wished that I had branched.
When you keep the trunk clean you allow the opportunity to quickly apply and push out bug fixes. You don't have to worry about the broken code you have that you conveniently branched off.
对于 Subversion，我同意 Ryan Duffield 的评论。 他提到的章节对使用哪个系统提供了很好的分析。
我问的原因是 Perforce 提供了一种完全不同的方式来从 SVN 或 CVS 创建分支。 另外，所有 DVCS 都给出了自己的分支理念。 您的分支策略将取决于您使用的工具。
仅供参考，Svnmerge.py 是一个帮助在 SVN 中合并分支的工具。 只要您经常使用它（每 10-30 次）提交，它就可以很好地工作，否则该工具可能会感到困惑。
For Subversion, I agree with Ryan Duffield's comment. The chapter he refers to provides a good analyses on which system to use.
The reason I asked is that Perforce provides a completely different way to create branches from SVN or CVS. Plus, there are all the DVCSs that give it's own philosophy on branching. Your branching strategy would be dictated by which tool(s) you're using.
FYI, Svnmerge.py is a tool to assist with merging branches in SVN. It works very well as long as you use it frequently ( every 10-30 ) commits, otherwise the tool can get confused.
无论选择哪种分支模式，您都应该尝试将分支保持为二叉树形式，如下所示：
No matter which branching pattern chosen, you should try to keep your branches in a binary tree form like this:
这是我过去使用过的非常成功的方法：
/trunk - 最前沿。 代码的下一个主要版本。 在任何给定时间可能工作也可能不工作。
/branches/1.0、1.1等。代码的稳定维护分支。 用于修复错误、稳定新版本。 如果是维护分支，则应编译（如果适用）并在任何给定时间准备好进行质量检查/运输。 如果是稳定分支，它应该编译并且功能完整。 不应添加新功能，不应重构，也不应清理代码。 您可以添加前缀来指示稳定分支与维护分支。
/分支/cool_feature。 用于高度实验性或破坏性的工作，可能会也可能不会进入主干（或维护分支）。 不保证代码编译、工作或以其他方式正常运行。 在合并到主线分支之前应该持续尽可能短的时间。
/tags/1.0.1、1.0.2、1.1.3a等。用于标记打包的& 已发货发布。 永远不会改变。 根据需要创建任意数量的标签，但它们是不可变的。
Here is the method I've used in the past with good success:
/trunk - bleeding edge. Next major release of the code. May or may not work at any given time.
/branches/1.0, 1.1, etc. Stable maintenance branches of the code. Used to fix bugs, stabilize new releases. If a maintenance branch, it should compile (if applicable) and be ready for QA/shipping at any given time. If a stabilization branch, it should compile and be feature complete. No new features should be added, no refactoring, and no code cleanups. You can add a pre- prefix to indicate stabilization branches vs maintenance branches.
/branches/cool_feature. Used for highly experimental or destructive work that may or may not make it into trunk (or a maintenance branch). No guarantees about code compiling, working, or otherwise behaving sanely. Should last the minimum time as possible before merging into the mainline branch.
/tags/1.0.1, 1.0.2, 1.1.3a, etc. Used for tagging a packaged & shipped release. Never EVER changes. Make as many tags as you want, but they're immutable.
我们的存储库看起来像：
/trunk 是您的标准、前沿开发。 我们使用 CI，因此必须始终构建并通过测试。
/branches 这是我们放置“批准的”大型更改的地方，即我们知道某些内容会进入主干，但可能需要一些工作并且会破坏 CI。 我们还致力于维护版本，它们有自己的 CI 项目。
/sandbox 每个开发者都有自己的沙箱，还有一个共享的沙箱。 这适用于您在不做实际工作时执行的“让我们向我们的产品添加 LINQ 提供程序”类型的任务。 它最终可能会进入主干，也可能不会，但它在那里并且处于版本控制之下。 这里没有 CI。
/vendor 标准供应商分支，用于我们编译的项目，但它不是我们维护的代码。
/ccnet 这是我们的CI标签，只有CI服务器可以在这里写入。 事后看来，我们会告诉我们将其重命名为更通用的名称，例如 CI、BUILDS 等。
Our repository looks like:
/trunk is your standard, bleeding edge development. We use CI so this must always build and pass tests.
/branches this is where we put 'sanctioned' large changes, ie something we KNOW will make it into trunk but may need some work and would break CI. Also where we work on maintenance releases, which have their own CI projects.
/sandbox each developer has their own sandbox, plus a shared sandbox. This is for things like "Lets add a LINQ provider to our product" type of tasks that you do when you are not doing your real work. It may eventually go into trunk, it may not, but it is there and under version control. No CI here.
/vendor standard vendor branch for projects where we compile but it is not code that we maintain.
/ccnet this is our CI tags, only the CI server can write in here. Hindsight would have told us to rename this to something more generic such as CI, BUILDS, etc.
看看这个 http://codicesoftware.blogspot.com/2010/03/ branching-strategies.html 以获得更好的解释
Take a look at this http://codicesoftware.blogspot.com/2010/03/branching-strategies.html for a better explanation
第一件事：KISS（保持简单愚蠢！）
*1）保持版本可维护 - 例如服务包、修补程序、错误修复，如果有必要和/或需要，可以将其合并到主干）
*2）major.minor.build.revision
经验法则：
--hfrmobile
The first thing: KISS (Keep it simple stupid!)
*1) Keep version maintainable - e.g. Service Packs, Hotfixes, Bugfixes which may be merged to trunk if necessary and/or needed)
*2) major.minor.build.revision
Rules of the thumb:
--hfrmobile
当版本准备好进行最终质量检查时，我们会进行分支。 如果在 QA 过程中发现任何问题，错误将在分支中修复、验证，然后合并到主干。 一旦分支通过了 QA，我们就会将其标记为发布版。 该版本的任何修补程序也会在分支上完成，经过验证，合并到主干，然后标记为单独的版本。
文件夹结构如下所示（1 个 QA 行、2 个修补程序版本和主干）：
We branch when a release is ready for final QA. If any issues are discovered during the QA process, the bugs are fixed in the branch, validated and then merged to the trunk. Once the branch passes QA we tag it as a release. Any hotfixes for that release are also done to the branch, validated, merged to the trunk and then tagged as a separate release.
The folder structure would look like this (1 QA line, 2 hotfix releases, and the trunk):
我们使用狂野、狂野、西方风格的 git 分支。 我们有一些分支具有按惯例定义的众所周知的名称，但在我们的例子中，标签实际上对于我们满足公司流程策略要求更重要。
我在下面看到您使用 Subversion，所以我想您可能应该查看 Subversion 中有关分支的部分预订。 具体来说，请查看分支维护<中的“存储库布局”部分/a> 和常见分支模式。
We use the wild, wild, west style of git-branches. We have some branches that have well-known names defined by convention, but in our case, tags are actually more important for us to meet our corporate process policy requirements.
I saw below that you use Subversion, so I'm thinking you probably should check out the section on branching in the Subversion Book. Specifically, look at the "repository layout" section in Branch Maintenance and Common Branch Patterns.
我在这里没有看到的替代方案是“变革分支”哲学。
如果您的主干是“当前版本”，而不是“狂野西部”，该怎么办？ 当一次只发布一个应用程序版本（例如网站）时，这种方法效果很好。 当需要新功能或错误修复时，会创建一个分支来保存该更改。 通常，这允许将修复程序迁移到单独发布，并防止您的牛仔编码人员意外添加您不希望发布的功能。 （通常它是一个后门 - “仅用于开发/测试”）
Ben Collins 的指导对于确定哪种风格最适合您的情况非常有用。
The alternative I'm not seeing here is a "Branch on Change" philosophy.
Instead of having your trunk the "Wild West", what if the trunk is the "Current Release"? This works well when there is only one version of the application released at a time - such as a web site. When a new feature or bug fix is necessary a branch is made to hold that change. Often this allows the fixes to be migrated to release individually and prevents your cowboy coders from accidentally adding a feature to release that you didn't intend. (Often it's a backdoor - "Just for development/testing")
The pointers from Ben Collins are quite useful in determining what style would work well for your situation.
Gnat 就各种问题编写了这篇出色的分解您可以找到有关分支策略的一些建议。
分支策略不存在一种，它适用于：
Jeff Atwood 的 帖子打破了很多可能性。 另一个要补充的是促销的概念（来自 Ryan Duffield 的链接）。 在此设置中，您有一个开发分支、测试分支和发布分支。 您可以升级您的代码，直到它到达发布分支并进行部署。
Gnat has written this excellent break down on the various bits of advice your can find on branching strategies.
There's not one branching strategy, it's what works for:
Jeff Atwood's post breaks down a lot of possibilities. Another to add is the concept of promotion (from Ryan Duffield's link). In this setup you have a dev branch, test bracnh and release branch. You promote your code up until it reaches the release branch and is deployed.
目前，我们有一个用于持续维护的分支，一个用于“新举措”的分支，这意味着“将来某个时候会出现的东西；我们不确定什么时候”。 我们偶尔也会有两个维护分支：一个为当前生产中的内容提供修复，另一个仍在质量检查中。
我们看到的主要优点是能够更快地响应用户请求和紧急情况。 我们可以对生产中的分支进行修复并发布它，而无需释放任何可能已签入的额外内容。
主要缺点是我们最终会在分支之间进行大量合并，这增加了某些内容发生错误的可能性。错过或错误合并。 到目前为止，这还不是问题，但这绝对是需要记住的事情。
在我们制定这个政策之前，我们通常在主干中进行所有开发，只有在发布代码时才进行分支。 然后我们根据需要对该分支进行修复。 它更简单，但不那么灵活。
We currently have one branch for ongoing maintenance, one branch for "new initiatives" which just means "stuff that will come out sometime in the future; we're not sure when." We have also occasionally had two maintenance branches going on: one to provide fixes for what is currently in production and one that is still in QA.
The main advantage we've seen is the ability to react to user requests and emergencies more rapidly. We can do the fix on the branch that is in production and release it without releasing anything extra that may have already been checked in.
The main disadvantage is that we end up doing a lot of merging between branches, which increases the chance that something will get missed or merged incorrectly. So far, that hasn't been a problem, but it is definitely something to keep in mind.
Before we instituted this policy, we generally did all development in the trunk and only branched when we released code. We then did fixes against that branch as needed. It was simpler, but not as flexible.