Git和SVN是我们代码开发中，最常用的两款代码管理软件。在这里我来写写我在工作中如何使用Git来管理我们的代码开发。
首先，我们是一个多人开发的团队，因此在开发过程中，少不了要进行多人协作的时候。不同的功能分支就成了家常便饭的事情了。咱先来看一副图：
这幅图里画的是我日常工作中，代码管理中Git分支的存在形式。从最上层的一行中可以看到，一般会存在一些这样的分支：
>>Master: 主分支；主要是稳定的版本分支，正式发布的版本都从Master拉。
>>Develop: 开发分支；更新和变动最频繁的分支，正常情况下开发都是在Develop分支上进行的。
>>Release：预发行分支；一般来说，代表一个版本的功能全部开发完成后递交测试，测试出Bug后进行修复的分支。
>>Features: 功能分支； 其实Features不是一个分支，而是一个分支文件夹。里面包含了每个程序员开发的功能点。Feature开发完成后合入Develop分支。
>>HotFix: 最希望不会被创建的分支；这个分支的存在是在已经正式上线的版本中，发现了重大Bug进行修复的分支。
介绍完了几个分支的主要功能，我们能谈谈一个具体的App软件版本开发中的流程。
- 软件版本的起点：A
需求总是在不断更新的。
上一次产品经理需求0.1的软件版本刚刚完成后，这不又来了新的版本需求0.2，这次一共两个功能点。幸好我们有Git，让并行开发成为可能。拉取Develop分支准备开干！
- 开发的起点：B
两名工程师，两个不同的需求，大师甲和大师乙各自领取一个功能点开干；从Develop拉取属于自己的分支，有单独的分支就不会被干扰：）
3、开发的终点：H
一周不到，两位大师就已经完成了属于自己的功能；从图上看，都有两次代码的提交。大师们各自开发的功能初步看似乎没有啥问题，但是我们的App版本是一个多功能的集合，是否合在一起也会没有问题？这时候大师们把属于自己的分支合入Develop，并删掉自己的工作Branche。编译，运行，Success!
4、预发行的起点：Release 0.2 节点(I)
大师们的能力果然与众不同，合入后没有一点问题，达到提交测试部的标准。新建Release 0.2 分支，代表一个里程碑式的事件。
5、Release 分支Bug宿命
世上没有哪个大师的代码是没有Bug的，大师甲和大师乙也不例外。这不，测试部刚拿到预发行的版本就曝出了2个Bug。
不过没有关系，能够复现的Bug对于我们来说就不是Bug。从Release 0.2拉取Bug修复分支。修好了，继续合进Release 0.2。谁叫Release就是这样的宿命呢。
6、版本发行的终点: M
但愿人长久，Bug不再有。
经过大师们艰苦卓绝的bug修复，终于通过了测试部的测试，也得到了产品经理们的认可，准备提交App Store审核。
Release合入Master分支，打上Tag 0.2，这就是这次的MileStone了。
当然也得记得Release合入Develop，之前这么多的bug也得在Develop上修复修复不是。做好了这些，Release就可以删啦。
7、救火队员一般的HotFix: N
好事多磨！AppStore刚发出去的App, 就有用户反馈Crash! 大师甲和大师乙临危受命!
从Master拉取HotFix分支来搞定它。原来是数组越界！分分钟搞定。完成后合入Master，版本更新为Tag 0.3，代表我们修复了重大问题。编译，运行，没问题，提交App Store等审核。
噢，one more thing, HotFix 也要合入Develop，又多了一个功能点（bug修复）不是。
8、新的轮回开始：P
1-> 7就是一个版本的开发过程中，我们的Git Flow流。到了最后，P和O节点拥有了相同的内容，就像在一开始的A和B那样。
这时候，我看见产品经理又拿着版本需求1.0向我走来......
参考：
