1 Git简介
Git 是一个分布式版本控制工具（便于代码保存，追踪代码的修改和代码回退），它的作者开发了Linux的 Linus Torvalds ，git目前在版本管理中应用十分普遍，本篇文章来自https://nvie.com/posts/a-successful-git-branching-model/ 和自己的理解。
git和其他版本管理工具的区别：
学过git的一定对这张图很熟悉，我曾经看这张图看的很吃力，现在总算能简单理解这张图，由于每个公司git使用方式都存在区别，我会按照自己的理解讲述这git模型图。
2 两个主要的分支
git分支模型中至少会有两个分支，master和develop，这两个分支是一直存在的，不会被删除。
master：
master分支对应线上版本，也就是已发布到app store的版本，是稳定的上线版本，总是和线上正运行的版本对应，每一次更新，最好添加对应的版本号标签（TAG）便于定位到特定发布版本。hotfix之后merge代码也需要添加tag。
develop：
develop分支对应开发分支，版本release之前的分支，平时开发工作都是在这个分支上，git中的HEAD也一般指向这个分支。
3 其他暂时（会被删除）分支
Feature branches： 具体到每个feature（功能分支，一个独立完整地功能）
Release branches： develop 分支被称为β版本，用于辅助版本发布。
**Hotfix branches：**线上版本有问题会创建Hotfix 分支进行修复
3.1 Feature branches
功能分支初始从develop分支拉取，通常是下一版（或者未来版本）开发新的功能的分支。功能分支是只要这个功能处于开发状态它就会存在，但确定开发完成并且开发的功能会被包含到下一次发布的版本最终会被合并到develop分支，如果不需要则可以删除。
举个例子：一个新闻app，已经做了好几个版本，最新一个版本要包含新闻查找功能，这个查找功能就可以最为一个feature。
app的某个版本可能需要开发多个新功能，所以可能会有多个feature，或者多个feature并行开发。
注意：
并不是所有的feature都会被合并到develop，有很多feature是试验性质的，或者做出来的效果不太好，就可能会被抛弃。
3.2 Release branches
Release branches：
Release分支是为新版本的发布做准备的，允许我们在最后时刻做一些细小的修改，类似（代码格式修改，代码小bug修改，版本号，开发时间修改等等）。Release分支一般从develop分支拉取，最终会合并到develop和master分支上（一定是两个），它的习惯命名方式为：release-*，这个新分支可能会存在一段时间，直到该发行版到达它的预定目标。
Release 分支的创建
当develop分支上的代码已经包含了所有即将发布的版本中所计划包含的软件功能（不能包含将来要发布的功能），并且已通过所有测试时，我们就可以考虑准备创建release分支了。
创建release分支，并被赋予版本号之后，develop分支就可以为“下一个版本”服务了。当一个release分支准备好成为一个真正的发行版的时候，还有一些问题需要完成，首先，release分支要合并到master上（记录发行版），然后，提交到master上必须打一个标签，以便以后更加方便的引用这个历史版本，最后，在release分支上的修改必须合并到develop分支上，以便未来发行版也包含这些bugs的修复（很重要，要把release上的修改合并到develop上）。
开发过程中可能有很多的测试apk版本，这里给出我们公司的规定：
Develop branch: related with the version that ready to test internal (Alpha version)对应α版本。
Release branch: related with the version that ready to release (Beta version)对应β版本。
注意：
注意release修复一些问题之后不但要合并到master还要合并到develop，这样再从develop拉取代码都是最新的。
4 热修复（hot fix）
热修复：已经上线的版本，忽然发现了一个影响用户使用的bug，需要进行修复。
hotfix一般从master分支派生，最终必须合并回master分支和develop分支，分支命名惯例：hotfix-*。
修复bug的过程：
从master拉取代码建立hotfix，然后修复bug，hotfix会被合并到master分支上，同时还需要合并到develop分支上，确保以后从develop拉取分支不会受以上bug的影响。
注意：
修复hotfix分支存在的bug后生成的apk就可以用于发版了，为什么此时需要把代码合并到master分支，为什么不等到最终develop merge到master（hotfix代码会被合并到develop上），因为master branch 必须和当前上线版本一致。
奉上一些微软的git规范：
• Master branch: related with the last release function
• Hotfix branch: to mitigate live site issue.
○ pull from master branch
○ push back to master branch when finish hotfix
○ Merge to develop branch if there is any code change
• Develop branch: related with the version that ready to test internal (Alpha version)
• Release branch: related with the version that ready to release (Beta version)
○ According to requirement that want to release, select change set to pull from Develop branch
○ Push to master branch with tag after bug fix
○ Push back to develop branch after release
• Feature branch: related with function, there are several feature branch, so name it like this: feature/xxxxx
○ Pull from develop branch when start a new feature
○ Push back to develop branch after finishing the feature
○ Delete this feature branch after finishing
• Dev branch: dev works on this, the purpose is to send pull request when you finish feature or bug fix, name it like this: dev//
○ Pull from develop branch or feature branch
○ Push back to feature branch