c# - 开发人员如何使用源代码控制，我试图找到在小型开发环境中进行源代码控制的最有效方法

Question

我在一个由 4 名 .Net 开发人员组成的小组中工作。我们很少同时处理同一个项目，但这种情况时有发生。我们使用 TFS 进行源代码控制。我最近的示例是我昨晚刚刚投入生产的一个项目，其中包括 2 个 WCF 服务和一个 Web 应用程序前端。我在一个名为“prod”的分支工作，因为该应用程序是全新的并且从未见过。现在该项目已经上线，我需要从 prod 分支分支以获取功能、错误等...

那么最好的方法是什么？

我是否简单地创建一个新分支并将旧分支存档并且不再使用它？

当我想部署到生产环境时，我是否要分支然后将我的分支更改合并回 prod 分支？

文件和程序集版本呢？它们目前为 1.0.0.0。他们什么时候改变，为什么？如果我修复了一个小错误，哪个数字会发生变化？如果我添加一项功能，哪个数字会发生变化？

我正在寻找的是您发现的有效管理源代码控制的最佳方式。我工作过的大多数地方似乎总是在途中或其他地方与源代码控制系统发生冲突，我只是想找出您发现的最有效的方法。

Answer 1

最好有一个单独的分支来支持每个已发布的版本，另一个分支用于继续开发。这样一来，无论您在主分支上开发的新功能如何，您始终可以为旧版本生成错误修复版本。

从长远来看，最好将主分支作为你的开发分支，并为每个特定的版本创建一个单独的支持分支；这使您的分支路径变短。 (我从事过一个项目，其中实际工作分支的路径类似于 main/release_1.0/release_1.1/release_1.5/release_2.0/release_2.1...不想走那条路 :-)

当然，您需要定期将在支持分支上所做的任何修复合并回主分支 - 至少在创建下一个版本之前。我的经验是，绝对不建议将合并留到最后一分钟——合并越晚，两个分支之间的差异就越大，因此遇到麻烦的机会就越大。如果合并更改的复杂性超过某个阈值，自动合并工具就会放弃……并且手动合并并不好玩。

在很大程度上，版本控制可能是个人偏好的问题。在小型项目中，您可能对 major.minor 版本方案感到满意，在大型项目中，您可能还希望使用补丁和/或构建版本号进行更精细的控制。

你需要制定一个版本策略然后坚持下去。例如。如果您使用 major.minor 版本方案，请为错误修复版本增加次要版本，为新功能版本增加主要版本。