C# 开发人员是如何使用源代码管理的，我正在努力寻找在小型开发环境中进行源代码管理的最有效的方法

我在一个由4.Net开发人员组成的团队中工作。我们很少在同一时间处理同一个项目，但它确实时常发生。我们使用TFS进行源代码控制。我最近的一个例子是我昨晚刚刚投入生产的一个项目，其中包括2个WCF服务和一个web应用程序前端。我在一家名为“prod”的分支机构工作，因为该应用程序是全新的，从未见过曙光。现在项目已经上线了，我需要从prod分支寻找特性、bug等

那么最好的方法是什么呢

我是否简单地创建一个新分支，并对旧分支进行归档，然后再也不使用它

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

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

---

我正在寻找的是您发现的有效管理源代码管理的最佳方法。我工作过的大多数地方似乎总是在某种程度上与源代码管理系统发生冲突，我只想了解您发现的最有效的方法。

最好有一个单独的分支来支持每个发布版本，另一个分支用于继续开发。通过这种方式，您可以始终为旧版本生成bug修复版本，而不依赖于您在主分支上使用的新功能

从长远来看，最好将主分支保留为您的开发分支，并为每个特定版本创建单独的支持分支；这样可以缩短分支路径。（我在一个项目中工作过，实际工作分支的路径类似于

main/release\u 1.0/release\u 1.1/release\u 1.5/release\u 2.0/release\u 2.1

…你不想走这条路：-）

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

版本控制在很大程度上是个人偏好的问题。在一个小项目中，您可能会对主版本和次版本方案感到满意，在一个较大的项目中，您可能也希望使用补丁和/或生成版本号进行更精细的控制

---

你需要制定一个版本策略，然后坚持下去。例如，如果您使用的是主版本。次版本方案，则在bugfix版本中增加次版本，在新功能版本中增加主版本。

标记/分支每个版本，使其保持不变。该委员会有一个发展科和一个支助科。在支持分支上进行支持/错误修复，然后在开发分支上开发新功能。您可以在不从开发分支引入新代码的情况下为生产软件生成临时错误修复版本，这些是您的次要版本增量，例如从1.0到1.1或1.01等。然后，当开发周期结束，您准备发布时，您可以合并开发分支和支持分支以生成版本，通过新的功能+错误修复，这些是您的主要版本，例如1.x到2.x或1.2x到1.3x。详细记录提交给支持部门的所有bug修复是非常重要的。这样，在合并支持和开发分支之前，您可以单独检查每个分支，以了解对开发分支可能产生的影响，例如，对支持分支的错误修复是否是对开发分支中已完全重写的内容的修复，因此应该从下一个主要版本中完全发布。

我正在重新发布我对先前问题的回答。YMMV，但它是我们当前开发过程的概述（我们这里有大约10个开发人员，并使用SVN进行源代码控制）：

这是我们典型的开发周期；我们是“虚拟敏捷”；并以2周的发布周期运行

所有项目都从主干的分支开始。没有例外

一旦项目完成并清除了代码审查，开发人员就可以将该分支合并到主干中。这样,；没有一个未经彻底审查的代码会进入后备箱。我们使用CruiseControl进行持续集成，因此在提交到主干之后，如果任何测试失败，开发人员负责修复它们。这些补丁放在后备箱上

下一版本发布前一周；我们创建一个发布“标签”（本质上是另一个分支），并将其发送给QA。如果此时还没有将代码合并回主干，那么下一个版本就不会使用它。（重要提示：这个版本的“标签”永远不会合并回主干。）因为QA发现了bug；它们被重新分配给开发者。当开发者修复它们时；它们的更改必须同时提交到release标签和trunk

当发布日到来时；我们释放了标签上的所有东西。在发布后修复的情况下；当我们在QA周期中时，我们遵循相同的指导原则，如果有人在发布标签被删除后将一个新项目合并到主干中；它不会因紧急修复而意外释放

泡沫，冲洗，重复

这可能无法回答您的问题本身；但希望这可以作为一个很好的外部视角，说明您可能希望如何设置您的开发过程。这不是我们最初的过程，而是我们在过去一两年中提出的，根据我的经验，这是一个跨越式的过程