很是清晰明了的GIT版本管理图

Git版本管理方法

  Git和SVN是咱们代码开发中，最经常使用的两款代码管理软件。在这里我来写写我在工做中如何使用Git来管理咱们的代码开发。
  首先，咱们是一个多人开发的团队，所以在开发过程当中，少不了要进行多人协做的时候。不一样的功能分支就成了屡见不鲜的事情了。咱先来看一副图：

GitFlow.png

  这幅图里画的是我平常工做中，代码管理中Git分支的存在形式。从最上层的一行中能够看到，通常会存在一些这样的分支：

>>Master: 主分支；主要是稳定的版本分支，正式发布的版本都从Master拉。>>Develop: 开发分支；更新和变更最频繁的分支，正常状况下开发都是在Develop分支上进行的。>>Release：预发行分支；通常来讲，表明一个版本的功能所有开发完成后递交测试，测试出Bug后进行修复的分支。>>Features: 功能分支； 其实Features不是一个分支，而是一个分支文件夹。里面包含了每一个程序员开发的功能点。Feature开发完成后合入Develop分支。>>HotFix: 最但愿不会被建立的分支；这个分支的存在是在已经正式上线的版本中，发现了重大Bug进行修复的分支。

  介绍完了几个分支的主要功能，咱们能谈谈一个具体的App软件版本开发中的流程。
一、软件版本的起点：A
  需求老是在不断更新的。
  上一次产品经理需求0.1的软件版本刚刚完成后，这不又来了新的版本需求0.2，此次一共两个功能点。幸亏咱们有Git，让并行开发成为可能。拉取Develop分支准备开干！

二、开发的起点：B
  两名工程师，两个不一样的需求，大师甲和大师乙各自领取一个功能点开干；从Develop拉取属于本身的分支，有单独的分支就不会被干扰：）

三、开发的终点：H
  一周不到，两位大师就已经完成了属于本身的功能；从图上看，都有两次代码的提交。大师们各自开发的功能初步看彷佛没 有啥问题，可是咱们的App版本是一个多功能的集合，是否合在一块儿也会没有问题？这时候大师们把属于本身的分支合入Develop，并删掉本身的工做 Branche。编译，运行，Success!

四、预发行的起点：Release 0.2 节点(I)
  大师们的能力果真不同凡响，合入后没有一点问题，达到提交测试部的标准。新建Release 0.2 分支，表明一个里程碑式的事件。

五、Release 分支Bug宿命
  世上没有哪一个大师的代码是没有Bug的，大师甲和大师乙也不例外。这不，测试部刚拿到预发行的版本就曝出了2个Bug。
  不过没有关系，可以复现的Bug对于咱们来讲就不是Bug。从Release 0.2拉取Bug修复分支。修好了，继续合进Release 0.2。谁叫Release就是这样的宿命呢。

六、版本发行的终点: M
  希望人长久，Bug再也不有。
  通过大师们坚苦卓绝的bug修复，终于经过了测试部的测试，也获得了产品经理们的承认，准备提交App Store审核。
  Release合入Master分支，打上Tag 0.2，这就是此次的MileStone了。
  固然也得记得Release合入Develop，以前这么多的bug也得在Develop上修复修复不是。作好了这些，Release就能够删啦。

七、救火队员通常的HotFix: N
  好事多磨！AppStore刚发出去的App, 就有用户反馈Crash! 大师甲和大师乙临危受命!
  从Master拉取HotFix分支来搞定它。原来是数组越界！分分钟搞定。完成后合入Master，版本更新为Tag 0.3，表明咱们修复了重大问题。编译，运行，没问题，提交App Store等审核。
  噢，one more thing, HotFix 也要合入Develop，又多了一个功能点（bug修复）不是。

八、新的轮回开始：P  1-> 7就是一个版本的开发过程当中，咱们的Git Flow流。到了最后，P和O节点拥有了相同的内容，就像在一开始的A和B那样。  这时候，我看见产品经理又拿着版本需求1.0向我走来......