Visual studio 源代码控制和bug修复的最佳实践

如果我们需要发布一个bug补丁，其中不包括已提交的当前开发，或其当前版本的任何更改，那么应该做些什么以使流程更安全并降低开销

---

我们目前正在一个小型（3名开发人员）团队中使用Subversion进行源代码控制，该团队主要在VisualStudio2008中开发。我们预计，该团队在未来一年内可能会分成8名开发人员，并且任何以前的版本支持都会变得更加复杂。虽然大多数客户都使用最新版本，但有些客户则更为落后。

如何：每个主要版本都有一个分支，根据需要对分支应用错误修复，并将其应用（或合并）回主干。

源代码管理可以非常轻松地处理此问题，并且是为此而设计的

当您达到释放的稳定期时，应执行分支。在下一版本完成之前，不要开始任何工作，这一点很重要

该版本的任何bug修复都应该在该分支中完成。这可以防止即将发布的新代码污染bug修复。一旦bug修复完成，您就可以将更改合并到主干中，并根据需要合并任何其他版本

---

不要忘记在注释中添加错误号，因为这将使跟踪提交更容易。

在我工作的地方，我们有几个项目同时工作。为了避免这个问题，我们有几个版本的源代码。例如，第一个版本是变体1.0。我们创建了这个版本的一个分支，比如变体2.0，用于所有未来的开发。如果我们需要做一个bug修复，我们会在主变体上做，它目前是1.0，可以发布。当变体2.0准备投入生产时，我们将其与主分支上的任何内容（在本例中为1.1）合并，并成为新的主干。有一次，我们有4个分支同时运行

---

合并代码可能会很耗时，并且您必须小心不要在合并过程中引入新的bug，但是如果您有一个合适的代码比较工具可用，那么它应该不会太糟糕。不久前，我们在10000个文件源目录上使用Beyond Compare进行了一次合并，只花了一个上午。

我们就是这样做的。很好！我认为这可能比在主干上开发、在主干上为每个主版本开发分支、在需要时从主干上开发分支要复杂得多。通过不断地从主干分支出去，可以更容易地看到发生了什么变化以及所有分支的共同点。