我是否应该使用特定规则来何时在源代码管理中进行分支？分支机构似乎很昂贵，因为它们要求团队有关于他们想要处理的功能应该去哪里的额外知识。
我们的开发团队有时会发现自己同时处理长期功能和短期功能。这意味着我们最终得到：
中继线 -Branch A（短期） -Branch B（长期）
完成后我们必须将A in合并到主干，然后将更改合并到主干中，重新进入B以确保这些编辑仍然有效。这太乱了。
我想知道我们是否可以通过使用标签（或标签，或引脚或任何您选择的源控制软件调用它）来减少分支。也许为长期项目分支是有意义的，但我们可以在向稳定版本应用标签后立即对主干中的短期项目进行编辑。这样，如果我们必须执行紧急错误修复，我们总是可以检索稳定的源代码，但我们不必处理分支。
您使用什么规则来决定何时进行分支？
答案 0 :(得分：1)
在一个小团队中，分支的时间是你不能直接进入主干的时候。使用svn（我猜其他版本控件也是如此），可以推迟决定分支，直到知道一个人无法进入主干的时间。
为了最小化分支的需要，可以通过在编译时或运行时标志内限制新功能代码，在主干本身中处理新功能。如果不需要，此方法还允许稍后关闭功能，使用该功能进行A / B分割测试实验等。
当然，采用这种方法，只要构建/测试套件在主干上中断，就可以进行连续测试，从而提供早期警报。
答案 1 :(得分：1)
减少分支的一种方法是直接在主干上实现新功能（特别是小功能）。我们就是这样做的：
答案 2 :(得分：0)
首先，这取决于您使用的工具。 Subversion中的分支比Mercurial或git更“昂贵”，因为合并更难。另一方面，它取决于您的项目/组织：您应该每个维护版本至少有一个分支。
答案 3 :(得分：0)
这取决于您使用的VCS。如果您使用的工具对合并有很好的支持，那么您应该随时分支。如有疑问，请创建一个新分支。如果UNIX纪元时间是偶数，那么你应该分支。如果它是奇怪的，你应该等一下，然后分支。如果您使用的工具不支持合并，那么您应该考虑更改工具。换句话说，请停止使用有必要提出此问题的工具。
答案 4 :(得分：-1)
通常在主线或主干上进行开发是不好的做法。主干应该用作主代码集，并且应该反映当前代表生产的代码。如果您尚未投入生产，它应该代表黄金副本，并且应该始终构建并进行自动回归测试。它不应该用于显示开发状态或活动。保护您的主干免受更改，并抵制诱惑开发人员检查并锁定主干上的代码的诱惑。当您准备将代码汇回主线时，我视图中的唯一更新应该是通过合并过程。 分支时，您应该考虑开发的目的，复杂性和持续时间。 •它是否支持开发新功能或大量开发的开发人员团队？ •您使用的是传统流程还是各种敏捷口味？ •是否适应生产补丁或修复的开发？ •您可以在分支上进行哪些开发，特别是测试活动，并且在构建，测试并认为可以发布衍生工件之前，您是否会保留分支？
有许多模型，但很少有人充分考虑＆＃34; build＆＃34;过程以及重新生成可释放工件的含义。
假设您有以下生命周期：DEV-＆gt; SYSTEM-INTEGRATIONTEST-＆gt; UAT-＆gt; PRE-PROD-＆gt; PRODUCTION。假设您从主线创建分支以适应开发和构建过程。您的开发\构建\测试周期一直持续到UAT。从这个分支产生的工件已经接受了充分的测试，认为它们可能适合于释放。您可以声明用户注销的工件也会暴露给系统和集成测试。
有些人主张此时将源代码合并到主干，并建议您在成功进行主干重建时创建一个RELEASE分支。对我来说，如果解决方案稳定并且在生产之前不需要进一步更改，那么这很好，否则您可能会将错误传播到其他地方。在变化中，它需要改变。
如果您在PRE_PROD中发现了问题，那么这些“修复”更改将在何处进行？许多人建议您可以直接在发布分支中进行代码更改。如果继续，此修改将生成新构建和一组新工件。您可以选择通过PRE_PROD将这些工件推回到生产中，因为底层代码已通过之前的测试进行了验证，并且为稳定版本而进行的修改被认为是无风险的？但是你有问题。
您无法声明已发布到预生产和随后生产的可执行文件\ artefacts已在您的较低环境中进行了测试。尽管信心很高，但发布分支构建的输出与开发构建的输出不同。这可能无法通过审核。
对我而言，分支是关于管理代码而不是构建输出或仅发布。如果您提倡分支发布和释放稳定（预先修复），您必须考虑上述风险并考虑重要回归测试的需要。
在trunk应该代表生产代码的基础上，除非先将其推送到生产环境，否则不能将代码推送到它。我主张创建一个支持开发，构建和发布的分支作为一个循环。为了避免分支机构的长寿和不必要的主干分歧（以及潜在的大爆炸冲突问题）尽可能地限制开发，并经常通过主干释放和遣返，以保持其他开发工作的最新状态。