如何应用主干-分支的代码管理方法？

@张凯丰 同学提出了以下问题，借这个问题，简要谈谈如何在项目中应用主干-分支的代码管理方法。

SVN 多人修改，如何管理 关于版本的问题

从问题描述可以看出，这是采用配置管理工具（代码版本控制工具）初期比较典型的问题，要解决此问题需要做以下调整：

1. 采用成熟的主干-分支代码管理方法；
2. 需要指定专职或兼职的人员来负责代码规划和管理，包括分支的创建和合并，通常称为配置管理员（CMO）；

先简单介绍一下主干-分支代码管理方法：

1. 代码库中创建三个目录：trunk、branches和tags，分别存放稳定代码、开发代码和用于生产环境的可发布代码；
2. Branches中可以有多个分支，可以按人员、用途或版本划分，具体视公司情况而定。
3. 通常把项目初始项目结构创建好，由CMO提交到trunk，CMO再基于trunk创建规划好的分支。

可行的解决方案：

1. CMO创建以下初始目录结构

Trunk

Branches

----dev

----test

Tags

2. 开发人员基于trunk创建个人开发分支到dev目录下，进行个人的开发，将代码部署到开发环境中，每天将通过单元测试的代码提交到此分支。
3. 测试人员将dev目录下某个或某些开发人员的开发分支合并到test的某个子分支下，将代码部署到功能测试环境，进行集成或系统测试。
4. 性能测试人员将test目录下通过集成或系统测试后的代码部署到性能测试环境，进行性能 测试。
5. CMO将test目录下通过性能测试的代码合并到trunk。
6. 当发布计划中的功能都已就绪，产品发布人员可以将trunk中的代码部署到生产预热环境中进行试运行。
7. 试运行没有发现问题，CMO将trunk代码创建一个正式的发布分支到tags中，可以用版本号命名。
8. 产品发布人员将tags中最新版本代码部署到生产环境中。
9. 随着时间的推移，配置库的目录可能的结构如下所示。

Trunk

Branches

----dev

----------john

----------tom

----------…

----test

---------test-20120901

---------test-20121001

---------test-20121101

---------test-…

Tags

----release v 0.0.1

----release v 0.1.0

----release v 0.2.0

----release …

最后，由于需要频繁的用到合并操作，就不可避免的遇到代码冲突。发生冲突时需要由相关的代码作者来一起讨论解决。根据以往的经验，可能通过以下方式来减少冲突发生的机会：

1. 功能尽可能的模块化，一个功能不应涉及到两个或多个模块的修改。
2. 不在代码库中保存项目的中间文件、临时文件或因人而异的配置文件。
3. 做好写权限管理，避免不必要的误修改操作。

以上希望能帮助@张凯丰解决碰到的问题。