什么时候是分支的正确时间，什么时候是错误的时间？
对于何时在源代码管理中进行分支，我应该使用特定的规则吗？分支似乎很昂贵，因为它们要求团队对他们想要处理的功能应该放在哪里有额外的了解。
我们的开发团队有时会发现自己同时开发长期功能和短期功能。这意味着我们最终得到：
Trunk -A分支（短期） -分支 B（长期）
完成后，我们必须将 A 合并到主干，然后将主干的更改合并回 B，以确保这些编辑仍然有效。很乱。
我想知道我们是否可以通过使用标签（或标签、引脚或任何您选择的源代码控制软件的名称）来减少分支。也许为长期项目进行分支是有意义的，但我们可以在将标签应用于稳定版本后，在主干中对短期项目进行编辑。这样，如果我们必须进行紧急错误修复，我们总是可以检索稳定的源代码，但我们不必处理分支。
您使用什么规则来决定何时分支？
Is there a specific rule I should be using for when to branch in source control? Branches seem to be expensive because they require that the team have extra knowledge about where the features they want to work on should go.
Our development team sometimes finds itself working on a long term feature and a shorter term feature at the same time. That means we end up with:
Trunk
-Branch A (Short Term)
-Branch B (Long Term)
After they complete we have to merge A in to the trunk, then merge the changes to the trunk back in to B to make sure those edits still function. It's messy.
I am wondering if we can cut down on branches by using Labels (Or tags, or pins or whatever your Source Control Software of choice calls it). Maybe it makes sense to branch for the longer term project, but we could just do the edits for the short term project right in the trunk after applying a label to the stable release. That way we can always retrieve the source code that was stable if we have to do an emergency bug fix, but we don't have to deal with the branch.
What rules do you use to decide when to branch?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
减少分支的一种方法是直接在主干上实现新功能（尤其是较小的功能）。我们是这样做的：
One way to reduce branching is to implement new features (especially smaller ones) directly on trunk. This is how we do it:
在小团队中，分支的时间是当你无法直接提交到主干时。使用 svn（我猜其他版本控制也是如此），可以推迟分支的决定，直到人们意识到无法提交到主干。
为了最大限度地减少分支的需要，可以通过在编译时或运行时标志内限制新功能代码来在主干本身中处理新功能。这种方法还允许稍后在不需要时关闭功能，使用该功能进行 A/B 拆分测试实验等。
当然，使用这种方法，它总是有助于进行持续测试，以便在构建/测试时发出早期警报。套件在行李箱上破裂。
In a small team, the time to branch is when you can't commit directly into the trunk. With svn (as I guess with other version controls as well), it is possible to postpone the decision to branch till the time one realizes that one cannot commit into the trunk.
To minimize the need to branch, a new feature can be worked on in the trunk itself by restricting the new-feature code within compile-time or run-time flags. This approach also allows to later turn off feature if not needed, do A/B split testing experiments with the feature, etc.
Of course with this approach it always helps to have a continuous testing that gives an early alert whenever the build/test-suite breaks on the trunk.
一方面，这取决于您使用的工具。 Subversion 中的分支比 Mercurial 或 git 中的分支更“昂贵”，因为合并更难进行。另一方面，这取决于您的项目/组织：每个维护的版本可能至少应该有一个分支。
For one thing, this depends on the tool you use. Branches are more 'expensive' in Subversion than in Mercurial or git, because merges are harder to do. For another, it depends on your project/organization: you should probably have at least one branch per maintained version.
这取决于您使用的 VCS。如果您使用的工具对合并具有良好的支持，那么您应该随时进行分支。如有疑问，请创建一个新分支。如果 UNIX 纪元时间是偶数，那么您应该分支。如果很奇怪，你应该等一下，然后分支。如果您使用的工具不能很好地支持合并，那么您应该考虑更换工具。换句话说，停止使用有必要提出这个问题的工具。
It depends on the VCS you are using. If you are using a tool that has good support for merging, then you should branch whenever you feel like it. When in doubt, create a new branch. If the UNIX epoch time is even, then you should branch. If it's, odd, you should wait a second, and then branch. If you are using a tool that doesn't support merging well, then you should consider changing tools. In other words, stop using a tool that makes it necessary to ask this question.
针对主线或主干线进行开发通常是不好的做法。主干应用作主代码集，并应反映当前代表生产的代码。如果您尚未投入生产，它应该代表黄金副本，并且应该始终构建并进行自动回归测试。它不应用于显示开发状态或活动。保护您的主干免受更改，并抵制允许开发人员检出并锁定主干上的代码的诱惑。在我看来，当您准备好将代码移回主线时，唯一的更新应该是通过合并过程。
当分支时，您应该考虑开发的目的、复杂性和持续时间。
• 是否支持开发人员团队开发新功能或进行实质性开发？
• 您使用的是传统流程还是现有的各种敏捷风格？
• 是为了适应生产补丁或修复的开发吗？
• 您将在分支上容纳哪些开发（特别是测试活动）？您是否会保留该分支，直到派生工件构建、测试并被视为可发布？
那里有很多模型，但很少有模型充分考虑“构建”过程以及重新生成可发布工件的影响。
假设您有以下生命周期：DEV->SYSTEM-INTEGRATIONTEST->UAT->PRE-PROD->生产。假设您从主线创建一个分支来适应开发和构建过程。您的开发\构建\测试周期一直持续到 UAT。该分支生成的工件已经经过充分的测试，认为它们可能适合发布。您可以声明用户签署的工件也接受了系统和集成测试。
有些人主张此时将源代码合并到主干，并建议您在成功重建主干后创建一个 RELEASE 分支。对我来说，如果解决方案稳定并且在生产之前不需要进一步更改，那就很好，否则您将面临在其他地方传播错误的风险。它总是需要改变。
如果您确实在 PRE_PROD 中发现了问题，那么这些“修复”更改将在哪里进行？许多人建议您可以直接在发布分支中进行代码更改。如果继续，此修改将生成一个新的构建和一组新的工件。您可以选择通过 PRE_PROD 将这些工件推回生产环境，因为底层代码已通过之前的测试进行了验证，并且为稳定版本而进行的修改被认为是无风险的？但你有一个问题。
您不能声明发布到预生产和随后生产的可执行文件\工件已在您的较低环境中进行了测试。尽管信心很高，但发布分支构建的输出与开发构建产生的输出不同。这可能会导致审核失败。
对我来说，分支是关于管理代码，而不是构建输出或仅仅是发布。如果您主张为发布和发布稳定性（预生产修复）进行分支，则必须考虑上述风险并结合进行重大回归测试的需要。
由于主干应该代表生产代码，因此除非先将代码推送到生产环境，否则无法将代码推送到其中。我主张创建一个分支来支持开发、构建和发布作为一个周期。为了避免分支寿命较长和与主干不必要的分歧（以及潜在的大爆炸冲突问题），请尽可能限制开发，并经常与主干一起发布和遣返，以保持其他开发工作的最新状态。
It’s normally poor practice to develop against the mainline or trunk. The trunk should be used as the master code set and should reflect the code that currently represents production. If you are not in production yet, it should represent the gold copy and should always build and be subjected to automated regression tests. It should not be used to show development status or activity. Protect your trunk from change and resist the temptation to allow developers to check out and lock code on a trunk. The only updates in my view should be via the merge process, when you are ready to repatriate your code to the mainline.
When branching you should consider the purpose, complexity and duration of the development.
• Is it to support a team of developers working on a new feature or a substantial piece of development?
• Are you using traditional processes or the various agile flavors that are out there?
• It is to accommodate the development of a patch or fix for production?
• What development and in particular, test activity will you accommodate on the branch and will you retain the branch until the derived artifacts are built, tested and deemed releasable?
There are many models out there but few give sufficient consideration to the "build" process and the implications of regenerating your releasable artifacts.
Let’s assume you have the following lifecycle: DEV->SYSTEM-INTEGRATIONTEST->UAT->PRE-PROD->PRODUCTION. Assume you create a branch from mainline to accommodate the development and build processes. Your development\build\test cycle continues right through to UAT. The artifacts produced from this branch have been exposed to sufficient testing to deem them potentially suitable for release. You are able to state that the artifacts signed off by the users were also exposed to system and integration testing.
Some folks advocate merging the source code to the trunk at this point and recommend that you create a RELEASE branch upon a successful trunk rebuild. For me this is fine if the solution is stable and requires no further change prior to production, otherwise you risk propagating bugs elsewhere. In variably it will need to change.
If you do unearth issues in PRE_PROD, where are these “Fix” changes going to be made? Many suggest that you can make the code changes directly in the release branch. If you proceed, this modification will produce a new build and a new set of artifacts. You may elect to push these artifacts back through PRE_PROD and on to production, as the underlying code has been validated through previous testing and the modifications made to stabilize the release are deemed risk free? But you have a problem.
You cannot state that the executables\artefacts released to pre-prod and subsequently production, have been tested in your lower environments. Despite confidence being high, the output from the release branch build is different from that produced from the development builds. This may fail audit.
Branching for me is about managing your code and not the build output or solely the release. If you advocate branching for release and release stabilization (pre-prod fixing), you must take the above risk combined with the need for significant regression testing into consideration.
On the basis that the trunk should represent production code, you cannot push code to it unless it has been pushed to production first. I advocate creating a branch that supports the development, build and release as a single cycle. To avoid branch longevity and unnecessary divergence from the trunk (and potential big bang conflict issues) limit the development as much as you can and release and repatriate often with the trunk to keep other development efforts current.