Git-Flow
分支定义
-
开发分支，更新和变动最频繁的分支，正常情况下开发都是在Develop分支上进行的。
-
功能分支，里面包含了每个程序员开发的功能点。Feature开发完成后合入Develop分支。
-
发布分支，一般来说，代表一个版本的功能全部开发完成后递交测试，测试出Bug后进行修复的分支。
-
补丁分支，这个分支的存在是在已经正式上线的版本中，发现了重大Bug进行修复的分支。
-
主干，主要是稳定的版本分支，正式发布的版本都从Master拉。
命名规则
master, develop, feature/, release/, hotfix/*
示意图
版本合并规则
-
发布分支 release/* -> 主干分支 master
-
热修复分支 hotfix/* -> 主干分支 master
-
功能分支 feature/* -> 开发分支 develop
-
发布分支 release/* -> 开发分支 develop
-
热修复分支 hotfix/* -> 开发分支 develop
详细说明
-
软件版本的起点：A 需求总是在不断更新的。 上一次产品经理需求0.1的软件版本刚刚完成后，这不又来了新的版本需求0.2，这次一共两个功能点。幸好我们有Git，让并行开发成为可能。拉取Develop分支准备开干！
-
开发的起点：B 两名工程师，两个不同的需求，大师甲和大师乙各自领取一个功能点开干；从Develop拉取属于自己的分支，有单独的分支就不会被干扰：）
-
开发的终点：S 一周不到，两位大师就已经完成了属于自己的功能；从图上看，都有两次代码的提交。大师们各自开发的功能初步看似乎没有啥问题，但是我们的App版本是一个多功能的集合，是否合在一起也会没有问题？这时候大师们把属于自己的分支合入Develop，并删掉自己的工作Branche。编译，运行，Success!
-
预发行的起点：Release 0.1 节点(J) 大师们的能力果然与众不同，合入后没有一点问题，达到提交测试部的标准。新建Release 0.1 分支，代表一个里程碑式的事件。
-
版本发行的终点: L 但愿人长久，Bug不再有。 经过大师们艰苦卓绝的bug修复，终于通过了测试部的测试，也得到了产品经理们的认可，准备提交App Store审核。 Release合入Master分支，打上Tag0.2，这就是这次的MileStone了。 当然也得记得Release合入Develop，之前这么多的bug也得在Develop上修复修复不是。做好了这些，Release就可以删啦。
-
救火队员一般的HotFix: Q 好事多磨！AppStore刚发出去的App, 就有用户反馈Crash! 大师甲和大师乙临危受命! 从Master拉取HotFix分支来搞定它。原来是数组越界！分分钟搞定。完成后合入Master，版本更新为Tag 0.3，代表我们修复了重大问题。编译，运行，没问题，提交App Store等审核。 噢，one more thing, HotFix 也要合入Develop，又多了一个功能点（bug修复）不是。
-
新的轮回开始：U 1-> 6就是一个版本的开发过程中，我们的Git Flow流。到了最后，S和U节点拥有了相同的内容，就像在一开始的A和B那样。 这时候，我看见产品经理又拿着版本需求1.0向我走来
