向小型团队介绍版本控制分支策略

我是最近刚从一家公司开始的承包商。

团队是由3位开发人员组成的，其中包括2位初级到中级开发人员，以及即将在同级别开始的另一位开发人员和我本人（6年xp）。对于这两个现有的开发人员来说，这是他们从大学/学院毕业后的第一份工作，而且他们之前从未有资深开发人员来监督他们的工作。

没有明确的版本控制策略。开发人员在主干上进行所有开发，然后从其开发机器直接部署到生产中。现有团队不熟悉分支。

我正在改变所有这些，并引入CI，TDD测试/登台/生产服务器等，以及与此相辅相成的版本控制策略。

源代码控制系统是TFS，我以前从未使用过。它被配置为一个巨型存储库。

我已经为他们写下了一些建议，但是考虑到团队的经验，我还有什么要补充/修改的？

版本控制政策

开发在主干上完成

如果更改估计要花费一周以上的时间，则应在分支上完成，并定期从主干合并到分支中，以阻止两者不同步。

释放为生产代码创建的分支。该分支应该只包含稳定的代码。我们可以有一个发布分支，每个sprint从主干更新一次，或者我们可以每周创建一个单独的发布分支。

如果需要进行影响生产代码的紧急错误修复，则在发布分支上进行修复，然后合并回主干。

如果我们采用一个发布分支策略，则主干将在每个sprint接近sprint末尾时合并到release分支中。

如果我们采用每个发布策略独立的分支，那么主干永远不会合并到Release分支中

在某些情况下，如果分支之间的差异太大，可能有必要在不同的分支上进行两次错误修复。如果我们正在做短距离的冲刺，那么这应该不会经常发生。

我计划有三台服务器。测试环境始终在存储库中运行最新代码。一个暂存环境，该暂存环境正在运行用于暂存/测试“ Release Candidate”代码和UAT用途的最新候选候选版本，以及生产环境。

我计划执行此操作的原因是，到目前为止，该客户端仅完成了内部软件。最新的项目是针对高知名度的媒体客户的，我的感觉是团队需要采用比他们目前更为专业的开发模型。

例如，此刻，用户可以通过错误报告给团队打电话。开发人员找到并修复该错误，在自己的计算机上进行快速测试，然后直接部署到生产中。没有自动化测试或其他任何东西。

事后看来，我认为功能分支太远了，我将删除它。

因此，从本质上讲，它可以归结为a）完全没有分支）b）发行分支和主干，以及c）每个发行版本和主干的发行分支。

我倾向于后者。我最初的想法是，我将同时拥有一个发布候选版本和一个发布版本，可以同时在单独的服务器（UAT /生产）上运行，但是实际上，主干在任何时间点都是发布候选版本，因此每个释放趋于疯狂。我唯一的想法是，如果我们不希望我们的涉众看到开发代码，那么我们可能需要一个单独的候选发布分支，但是YAGNI以及所有这些.....

对于由3-4个开发人员组成的团队，您建议的方式太多。

您创建的每个分支都是额外的开销，伴随而来的是一定的开销（合并所花费的时间，跟踪所处位置等）。您需要确保拥有分支机构所获得的收益超过成本。

请记住，分支的唯一真正好处是代码隔离。这意味着您需要一个具体的理由来隔离代码。

每个 sprint 都有一个单独的发布分支是很疯狂的。为什么您需要一个Sprint中的代码，而下一个Sprint中却没有代码？为什么不只有一个稳定的发布分支随每个sprint结转？

如果更改估计要花费一周以上的时间，则应在分支上完成，并定期从主干合并到分支中，以阻止两者不同步。

在您考虑了开发，开发人员测试，日常中断和其他活动等之后，几乎所有非平凡的新功能都将至少实时地花费一周。

另外，什么是“常规合并”？日常？每周？您所做的每个合并都需要时间-您需要确保更改后目标合并分支能够构建和运行。在小型团队中，频繁合并会产生大量开销。

我们有一个由4个开发人员组成的团队，致力于处理超过1百万行的代码库，这就是我们的运作方式：

• 完成所有开发的主分支
• 每个主要版本一个分支（每年大约执行一次）

一个主要规则是：不要检入未构建的代码。

而已。简单，易于理解，即可获得我们所需的隔离（我们可以随时为任何版本创建发行版本）。

在一个分支上完成所有开发工作的好处：

1. 开发人员始终彼此同步。无需痛苦的合并，因为两个开发人员在自己的分支机构离开了数周，创建了不兼容的更改。
2. 在同一天发现损坏的内部版本。我们有一个每晚生成的版本，可在main上运行最新的代码。如果有人签入由于某种原因而无法构建的代码，我们将立即知道。
3. 由于每个人都始终在处理同一代码，因此早日发现错误的机会增加了。
4. 除了发布分支的目标修复程序外，没有合并开销。在一个小的团队中，这是最大的团队。

您已经为他们写下了一些指针，但是您还没有解释为什么您的方法比他们已经使用的方法更好。这可能是有问题的。如果您本着“我们会按照我的方式去做，因为我有六年的专业经验，而您却没有”的精神（阅读您的问题，它看起来就是这样），请准备好被仇恨您的团队成员将竭尽所能地应用您的概念。

他们有需要解决的问题吗？首先回答这个问题至关重要，因为他们实际上确实有问题并且会欢迎您的建议，或者他们像现在这样工作时表现很好，而您只是在推动他们的工作方式，只是因为您更愿意这样工作。

最终，强迫他们使用分支机构会产生极大的负面影响。使用树干很容易，尤其是在敏捷环境中。开发人员将更改提交到主干，最终处理较小的冲突，并且这些更改将由Continuous Integration平台立即使用。设有分支机构：

• 开发人员必须考虑更改的位置，

• 有人必须管理分支并从分支合并到主干，

• 分支之间的合并比提交的频率要少，这意味着某人必须处理比两次提交之间的冲突更大，更难以处理的冲突，

• 每次提交不一定都进入持续集成的方式，这会延迟开发人员获得有关提交可能具有的效果的信息（尤其是回归）。

事实：

现有团队不熟悉分支

使事情变得更糟。我曾在一个没有经验的程序员团队中工作，一个没有经验的经理决定与分支机构一起工作。这会浪费很多时间，而对于有期限的项目，这正是您要避免的事情。

如Mainma所说，小心分支。您提到每隔几周分支一次，真的有必要建立很多分支吗？

另外，您也可以使用“拉”模型而不是“推”模型。如果使用的是Git或Mercurial，则可以让集成服务器在推送到中央服务器之前先验证它们的更改。在TFS中，您可以使用gated check-ins进行类似的操作。这样，您可以进行验证并避免分支的复杂性。