这两天抽时间把《软件发布方法》里面关于源代码控制的章节看了一边。得到了一点提示。 目前项目面临的一个问题就是对于同一个机能里的程序存在设计变更、内部连接测试、外部连接测试 3 方面的修改需要同时对应，而且整个项目的所有机能正在进行品质向上的工作。因为测试的周期性，导致必须要等所有的变更同时完成才能够集成到下一个阶段的外部连接测试中去。 当初面临这个问题的时候首先想到的就是进行分支管理。但是定不下一个好的分支管理策略，而且担心合并产生的风险，最终还是没有采用。 从《软件发布方法》里得到了一点思路。可以按照变更和 bug 为单位进行分支，在变更或者 bug 的对应单体测试完成以后再合并到主干上。 更具体一点讲，在开发团队确定下某个变更 ID 或者 BugID 需要修正的源代码范围以后，向配置管理人员提交变更申请，配置管理人员从主干上，对要发生变更的源代码群进行分支，分支名应该就是变更或者 bug 的 ID。然后开发人员在分支上进行修正以及单体测试。通过以后提交合并申请。由配置管理人员完成向主干的集成。然后再从主干上 checkout 代码进行内部连接测试。这样的话，即使同一个代码同时有好几个变更在进行，也可以互不影响。从一定程度上能够提高对应的速度。唯一的风险就是合并。但是合并以后的代码如果进行内部连接测试的话，应该能够发现合并造成的错误。当然，负责合并集成的人应该经验比较丰富。 而品质向上的工作应该在主干上就能够直接进行。然后只要把分支上对应修改的时候发生的代码变更集成到主干上就可以了。当然，在合并完成以后，对合并以后的源代码还是需要进行一下品质向上检查的。这就增加了一些工作量。 上面的分支策略产生的分支可以被叫做任务分支。另外还有一种分支叫做集成分支。这两种分支可以并存。 对于我们的项目来说，每周末向外部连接测试的下一个 cycle 发布的代码都可以采用集成分支的方法。目前因为每次发布后如果出现错误在主干上直接修正，所以没有用分支，而是采用标签的方法标注每一次发布的内容。
对于我们的项目来说，每周末向外部连接测试的下一个 cycle 发布的代码都可以采用集成分支的方法。目前因为每次发布后如果出现错误在主干上直接修正，所以没有用分支，而是采用标签的方法标注每一次发布的内容。------------------ 如果发布后错误直接在主干上修正，那假如 a3 发布后出现的错误在主干上修正了，a3 之前的发布掉的版本 a0，a1，a2 也出现了同样的错误，而这些版本都是客户正在使用的，要如何来修正呢？
你们每次修正就相当于发布一个 hotfix，对吧？a0,a1,a2,a3,就是 hotfix1，2，3，4
有几点需要你提供更多的信息 1）你们发布每个 hotfix，是做成 installer 的形式，还是直接替换文件？还是 server 上打了 patch 之后，客户端自动升级？ 2）hotfix1，2，3，4 之间时候有依赖关系呢？比如，hotfix1，2，3 是分别修正的不同的 bug，但是 hotfix4 是在 hotfix1 的基础上继续做的修改。 如果四个之间没有依赖关系，那么依次打上 hotfix1，2，3，4 就可以了。 如果有依赖，比如上边说的 hotfix4，不但修正了 hotfix1 中的 bug，还修正了其它的 bug，那么就要让打了 hotfix1 的客户升级到 hotfix4 了，没打 hotfix1 的，让他直接装 hotfix4
这种 hotfix 之间的依赖关系，要在每个 hotfix 发布的 readme 文件里清楚的写出来。