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