作为一个程序员,一定要会使用版本控制.当代码出现问题时才知道版本控制的好处.
工具
常用的版本控制工具有:
· SVN
· Git
在这里我不叙述怎样使用版本控制工具,只是想总结一下自己在项目中关于版本控制的经验.
过程
实际项目中,代码的版本控制大概如下:
1. 创建项目
2. 开发功能
3. 第一个内测版本
4. 第N个内测版本
5. 第一个公测版本
6. 第N个公测版本
7. 第一个正式版本
8. 修复稳定版bug
9. 开发新功能
其中3 ~ 7可能会有很多,也可能很少,视公司情况而定.
以下以SVN为例,来说明这一功能.
前提
项目名称:Chat
三端:Android,IOS,Server
创建根目录
源码根目录如下:
[代码]java代码：
1 2 3 4 5 6 7 | |-Chat |-trunk |-Android |-IOS |-Server |-branches |-tag |
开发
各端在各自的Trunk分支下进行开发,直到第一个稳定的内测版本.
内测
当发布第一个内测版本时,此时应在tag分支下添加tag,如下:
[代码]java代码：
01 02 03 04 05 06 07 08 09 10 11 12 13 | |-Chat |-trunk |-Android |-IOS |-Server |-branches |-tag |-Android |-inner_test_1.0.0 |-IOS |-inner_test_1.0.0 |-Server |-inner_test_1.0.0 |
无论哪个端发布版本都应在tag分支下添加tag.
公测
内测几版之后,可以进行公测,测试继续在Trunk分支下开发,然后在发布公测版本时在tag分支下添加tag.如下所示:
[代码]java代码：
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 | |-Chat |-trunk |-Android |-IOS |-Server |-branches |-tag |-Android |-inner_test_1.0.0 |-inner_test_1.0.1 |-inner_test_1.0.2 |-public_test_1.0.3 |-public_test_1.0.4 |-IOS |-inner_test_1.0.0 |-Server |-inner_test_1.0.0 |
正式版
当发布正式版之后,要做的有:
1. 在tag分支下添加tag
2. 在branches分支添加开发版分支
如下所示:
[代码]java代码：
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 | |-Chat |-trunk |-Android |-IOS |-Server |-branches |-Android |-BaseDev |-tag |-Android |-inner_test_1.0.0 |-inner_test_1.0.1 |-inner_test_1.0.2 |-public_test_1.0.3 |-public_test_1.0.4 |-release_1.0.5 |-IOS |-inner_test_1.0.0 |-Server |-inner_test_1.0.0 |
BaseDev分支的意义在于:在此版本上只做针对上一稳定版的bug修复以及短期迭代的任务.
迭代
迭代分为:快速迭代和长周期迭代.
快速迭代可能是:
1. 针对上一版本的bug修复
2. 针对已有功能细节上的优化
3. 添加可以快速完成的功能
长周期迭代可能是:
1.某一功能在短期内无法完成,需要切分多个快速迭代版本
对于快速迭代,可以在BaseDev分支下开发,等到迭代完毕后将BaseDev更新至Trunk分支.
何时需要建立新的分支?
1. 新功能暂时无法确定是否在下一版本发布
2. 新功能开发周期长,分拆为多个版本后但体验不佳,不能独立发布
比如Chat项目新添加功能空间(Space),该功能无法在快速迭代中完成,开发周期可能较长.此时就需要在branches下添加分支.如:
[代码]java代码：
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 | |-Chat |-trunk |-Android |-IOS |-Server |-branches |-Android |-BaseDev |-Space |-tag |-Android |-inner_test_1.0.0 |-inner_test_1.0.1 |-inner_test_1.0.2 |-public_test_1.0.3 |-public_test_1.0.4 |-release_1.0.5 |-IOS |-inner_test_1.0.0 |-Server |-inner_test_1.0.0 |
写在最后
要尽可能地少建立分支,因为合并代码的代价太高!!!
要尽可能地少建立分支,因为合并代码的代价太高!!!
要尽可能地少建立分支,因为合并代码的代价太高!!!
1. 尽可能拆分迭代任务,使之为一个可以快速迭代的任务.
2. 对于代码的编译最好使用自动编译,来控制安装包的版本.比如: Jenkins
共同学习，写下你的评论
评论加载中...
作者其他优质文章
