代码版本管理

原创
2018/08/30 15:51
阅读数 2.3K

写在前面

为何需要代码版本管理,

想想,没有版本管理,代码全在master分支上修改,

如果准备要发版本了,正在修复BUG的时候,突然来了不是此版本迭代的新需求,这么办?

如果在开发新需求的时候,突然临时有一个突发的紧急BUG需要修复,马上上线的,这么办?

如果正在开发新需求,又来了一个不是此版本迭代的新需求,这么办?

如果此时的代码经过几轮版本发布的洗礼了,想看看以前发布过的代码,这么办?

还有 代码分支混乱,命名混乱,乱七八糟的合并等等问题.

与其以后爬坑,不如现在好好的做好代码版本管理,减少风险,自己开发也舒服.

下面的内容将围绕 git flow 来讲解.(git flow虽然不一定是最优)

工欲善其事必先利其器

强烈推荐 SourceThree,它是一个很好的 git GUI界面,支持 git flow.

sourcetree 跳过注册问题

导入你的项目后,进行 git flow 的初始化

工程会多出一个 develop.

分支的意义

master:保护分支,功能稳定 且 完整的 随时可发布的代码, 不可以在master 分支上直接开发和提交代码,一般是 release合并回来的.

develop:开发主分支,代码最新最全 的分支.

feature:特性分支

hotfix:紧急BUG修复分支,一般是紧急的问题需要修复 从 master 上拉出分支. 完成修复后,合并回 master, develop,并且打上 tag版本标签.

release:发布分支,此分支只修改BUG与测试,直到稳定 版本发出去后,合并回 develop, master,并且打上 tag版本标签,后续会完整介绍.

版本控制-开发流程

  • 新需求开发

敏捷开发中的 需求池 或者 定了几个需求,然后确定某个版本,该如何使用 git flow.

比如,定了 v2.0.0 版本 有 3个 需求 AAA_dev, BBBB_dev, CCCC_dev, 迭代为三周.

不管几个人,先建立3个 feature 分支,开发完毕的时候再合并回来develop分支.

使用 sourceTree 开发新需求功能:

  • 开发完成,进入提测

假设已经完成 v2.0.0 的 3 个 需求的功能开发,进入测试阶段,测试报了一些问题,这个时刻该如何操作:

其实在进入测试阶段,就应该进行下面的操作,合并v2.0.0所有的 feature 回到develop,在SourceThree在进行功能完成的点击.

记得要删除 v2.0.0 所有的 feature.

最后 在 develop的基础上拉一个 release 分支, 上面已经介绍过 release 的作用,只修复BUG和测试.

SourceThree 上点击 建立新的发布版本.

  • 测试完成,准备发布

release/v2.0.0 修复了BUG,经过测试,已经稳定,APP准备发布,该如何操作.

在 sourceTree 上点击 完成版本发布,将 release/v2.0.0 合并到 develop, master,并且打上 v2.0.0 的tag标签.

这个时候基本完成一次迭代以及代码版本控制.

版本控制-特殊处理

  • 紧急BUG处理

扩展知识

Trunk Based Development

参考资料

git flow的使用

展开阅读全文
打赏
0
1 收藏
分享
加载中
更多评论
打赏
0 评论
1 收藏
0
分享
返回顶部
顶部