概述

这是产品研发管理系列文章的第二篇：使用SubVersion进行代码管理。
介绍怎样使用SubVersion的资料已经很多，这里不准备介绍怎样使用SubVersion。这篇文章主要介绍怎样进行代码版本管理。

使用SubVersion进行代码管理

• 时间点(1)
  
  • (1)的起始时间是3.0开发的开始。
  • 在(1)期间，没有任何用户使用3.0（因为它还没有发布），所以所有开发人员直接在3.0Trunk上开发。
  • (1)的结束时间是3.0开发的结束时间。结束时发布3.0产品，在SVN上创建3.0 Tag，同时创建3.1 F000 Branch。这时3.0 Trunk自动变成3.1 Trunk。
• 时间点(2)
  
  • (2)的起始时间是3.1开发的开始。
  • 在(2)期间，因为开始有用户安装使用3.0，所以3.1所有开发人员的开发工作在3.1 F000 Branch上进行。
  • 如果在(2)期间，用户报告3.0的Bug，并且需要马上修复。那么：
    
    • 在3.1 Trunk上对问题进行修复，并且发布补丁包。
    • 将此改动合并到3.1 F000 Branch上。
  • (2)的结束时间是3.1 F000开发的结束时间。结束时发布3.1 F000产品。此时做以下事情：
    
    • 合并代码之前，在3.1 Trunk上建立Tag，如：3.0 20150601。用来表示将3.1 F000合并进来之前的代码。
    • 将3.1 F000 Branch的代码合并到3.1 Trunk上。并且锁定3.1 F000代码避免任何进一步的修改。
    • 从3.1 Trunk上创建3.1 M010 Branch，用于进行3.1 M010的开发。
• 时间点(3)，(4)，(5)和(6)
  
  • 基本和时间点(2)一样。
  • (5)是3.2的开始。

注：
1. (5)是3.2的开始，它和(3)，(4)的操作方式没有根本的区别，但有些细小的区分，主要是安排不同类型的改动。
一般我们把相对大的功能/改动放到一个新的版本里边。(3)和(4)作为(2)的升级，主要负责修复3.1的Bug和小功能的改进。把相对大一点的功能或者相对底层的改动放在3.2里边，也就是(5)里边。
2. 到底有多少个M0X0，由产品经理根据用户反馈的问题和待开发的需求列表决定。
3. 在一个迭代周期开始前，需求都搜集到位。我们使用的迭代周期是2个月，包括需求讨论、设计开发、测试。

注意事项

根据我们使用下来的情况，有以下注意事项：

• 如果修复Bug，可以在Trunk或者Branch上做，但是一定要使用SubVersion的合并功能，而不是在Trunk和Branch上分别改两遍。如果改两遍，造成的结果是在要将Branch合并到Trunk上出现冲突。
• 不是任何时候都适合进行任何类型的改动。比如有些核心数据结构的变动，将它放在小版本升级后的第一个迭代进行。这种大的改动得找时机，避免对用户造成升级困难，或者用户需要重新装载所有数据。
• 在迭代开发结束是在Branch上做发布的；但是维护是将Branch的代码合并到Trunk后，在Trunk上维护。合并代码的时候需要非常小心，保证Branch上的代码和合并以后Trunk的代码一样非常关键。如果不一样会造成这种情况：第一个从Branch上发布的产品没有问题；后来为了修复一个Bug，从Trunk上发布一个补丁包后，出现了第一个发布没有出现的问题。