向小型团队介绍版本控制分支策略
我是最近刚从一家公司开始的承包商。 团队是由3位开发人员组成的，其中包括2位初级到中级开发人员，以及即将在同级别开始的另一位开发人员和我本人（6年xp）。对于这两个现有的开发人员来说，这是他们从大学/学院毕业后的第一份工作，而且他们之前从未有资深开发人员来监督他们的工作。 没有明确的版本控制策略。开发人员在主干上进行所有开发，然后从其开发机器直接部署到生产中。现有团队不熟悉分支。 我正在改变所有这些，并引入CI，TDD测试/登台/生产服务器等，以及与此相辅相成的版本控制策略。 源代码控制系统是TFS，我以前从未使用过。它被配置为一个巨型存储库。 我已经为他们写下了一些建议，但是考虑到团队的经验，我还有什么要补充/修改的？ 版本控制政策 开发在主干上完成 如果更改估计要花费一周以上的时间，则应在分支上完成，并定期从主干合并到分支中，以阻止两者不同步。 释放为生产代码创建的分支。该分支应该只包含稳定的代码。我们可以有一个发布分支，每个sprint从主干更新一次，或者我们可以每周创建一个单独的发布分支。 如果需要进行影响生产代码的紧急错误修复，则在发布分支上进行修复，然后合并回主干。 如果我们采用一个发布分支策略，则主干将在每个sprint接近sprint末尾时合并到release分支中。 如果我们采用每个发布策略独立的分支，那么主干永远不会合并到Release分支中 在某些情况下，如果分支之间的差异太大，可能有必要在不同的分支上进行两次错误修复。如果我们正在做短距离的冲刺，那么这应该不会经常发生。 我计划有三台服务器。测试环境始终在存储库中运行最新代码。一个暂存环境，该暂存环境正在运行用于暂存/测试“ Release Candidate”代码和UAT用途的最新候选候选版本，以及生产环境。 我计划执行此操作的原因是，到目前为止，该客户端仅完成了内部软件。最新的项目是针对高知名度的媒体客户的，我的感觉是团队需要采用比他们目前更为专业的开发模型。 例如，此刻，用户可以通过错误报告给团队打电话。开发人员找到并修复该错误，在自己的计算机上进行快速测试，然后直接部署到生产中。没有自动化测试或其他任何东西。 事后看来，我认为功能分支太远了，我将删除它。 因此，从本质上讲，它可以归结为a）完全没有分支）b）发行分支和主干，以及c）每个发行版本和主干的发行分支。 我倾向于后者。我最初的想法是，我将同时拥有一个发布候选版本和一个发布版本，可以同时在单独的服务器（UAT /生产）上运行，但是实际上，主干在任何时间点都是发布候选版本，因此每个释放趋于疯狂。我唯一的想法是，如果我们不希望我们的涉众看到开发代码，那么我们可能需要一个单独的候选发布分支，但是YAGNI以及所有这些.....