版本控制总结

发布时间:2019-06-10 发布网站:脚本宝典
脚本宝典收集整理的这篇文章主要介绍了版本控制总结脚本宝典觉得挺不错的,现在分享给大家,也给大家做个参考。

作为一个程序员,一定要会使用版本控制.当代码出现问题时才知道版本控制的好处.

工具@H_777_4@

常用的版本控制工具有:

在这里我不叙述怎样使用版本控制工具,只是想总结一下自己在项目中关于版本控制的经验.

过程

实际项目中,代码的版本控制大概如下:

  1. 创建项目

  2. 开发功能

  3. 第一个内测版本

  4. 第N个内测版本

  5. 第一个公测版

  6. 第N个公测版本

  7. 第一个正式版

  8. 修复稳定版bug

  9. 开发新功能

其中3 ~ 7可能会有很多,也可能很少,视公司情况而定.

以下以SVN为例,来说明这一功能.

前提

项目名称:Chat
三端:AndROId,IOS,Server

创建根目录

码根目录如下:

|-Chat
    |-trunk
        |-Android
        |-iOS
        |-server
    |-branches
    |-tag

开发

各端在各自的Trunk分支下进行开发,直到第一个稳定的内测版本.

内测

当发布第一个内测版本时,此时应在tag分支下添加tag,如下:

|-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.如下所示:

|-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分支添加开发版分支

如下所示:

|-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下添加分支.如:

|-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

如果有好的方法,请留言或者联系我哦.点此查看联系方式

更多文章请移步我的博客:DevWiki's Bolg

脚本宝典总结

以上是脚本宝典为你收集整理的版本控制总结全部内容,希望文章能够帮你解决版本控制总结所遇到的问题。

如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典推荐好友。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。