▌写在前面
为何需要代码版本管理，
想想，没有版本管理，代码全在master分支上修改，
如果准备要发版本了，正在修复BUG的时候，突然来了不是此版本迭代的新需求，这么办？
如果在开发新需求的时候，突然临时有一个突发的紧急BUG需要修复，马上上线的，这么办？
如果正在开发新需求，又来了一个不是此版本迭代的新需求，这么办？
如果此时的代码经过几轮版本发布的洗礼了，想看看以前发布过的代码，这么办？
还有 代码分支混乱，命名混乱，乱七八糟的合并等等问题.
与其以后爬坑，不如现在好好的做好代码版本管理，减少风险，自己开发也舒服.
下面的内容将围绕 git flow 来讲解.(git flow虽然不一定是最优)
▌工欲善其事必先利其器
强烈推荐 SourceThree，它是一个很好的 git GUI界面，支持 git flow.
导入你的项目后，进行 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处理
▌扩展知识
▌参考资料
转播
