一、Git介绍
Git是一个项目源码管理系统，在多人合作开发过程中是至关重要的。在项目开发中，我们可以通过Git客户端(Github、Tower、Tortoise等)或者通过命令行来使用Git，关于Git基础操作的命令参考文章Git基本操作命令。即使是在独立开发过程中，使用Git管理项目也是有很多的好处的，便于记录版本历史、随时进行版本回退等等。协作则必须有一个规范的工作流程，让大家有效的合作，使得项目井井有条的发展下去。下面就介绍下Git中常用的三种Git工作流程。
二、三种常用的Git工作流程(Git Flow、Github Flow、GitLab Flow)介绍
1.Git Flow：
Git Flow是最早的一种Git工作流程，他有两个特点:(1).项目存在两个长期分支; (2).项目存在三中短期分支
长期分支：develop分支、master分支。develop分支用于开发，存放最新的开发版；master分支用于存放最新的稳定版本。
短期分支：功能分支(feature branch)、补丁分支(hotfix branch)、预发分支(release branch)。这三种短期分支在完成开发后会被合并 到develop分支或者master分中，然后被删除掉。
评价： Git flow的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将master当作默认分支，可是开发 是在develop分支进行的，这导致经常要切换分支，非常烦人。
更大问题在于，这个模式是基于"版本发布"的，目标是一段时间以后产出一个新版本。但是，很多网站项目是"持续发布"， 代码一有变动，就部署一次。这时，master分支和develop分支的差别不大，没必要维护两个长期分支。
模型图：
2.Github Flow:
Github flow 是Git flow的简化版，专门配合"持续发布"。它是 Github.com 使用的工作流程。
操作流程： 第一步：根据需求，从master拉出新分支，不区分功能分支或补丁分支。
第二步：新分支开发完成后，或者需要讨论的时候，就向master发起一个pull request（简称PR）。
第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。 对话过程中，你还可以不断提交代码。
第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合 并也可。）
评价： Github flow 的最大优点就是简单，对于"持续发布"的产品，可以说是最合适的流程。
问题在于它的假设：master分支的更新与产品的发布是一致的。也就是说，master分支的最新代码，默认就是当前的线上 代码。
可是，有些时候并非如此，代码合并进入master分支，并不代表它就能立刻发布。比如，苹果商店的APP提交审核以后， 等一段时间才能上架。这时，如果还有新的代码提交，master分支就会与刚发布的版本不一致。另一个例子是，有些公司有 发布窗口，只有指定时间才能发布，这也会导致线上版本落后于master分支。
上面这种情况，只有master一个主分支就不够用了。通常，你不得不在master分支以外，另外新建一个production分支跟 踪线上版本。
模型图：
3.GitLab Flow
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
它是 Gitlab.com 推荐的做法。Gitlab flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支master，它是所有其他分支
的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
持续发布模式：对于"持续发布"的项目，它建议在master分支以外，再建立不同的环境分支。比如，"开发环境"的分支master，"预发环境"的分支是pre-production，"生产环境"的分支是production。开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到master，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。只有紧急情况，才允许跳过上游，直接合并到下游分支。
版本发布模式：对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从master分支拉出一个分支，比如2-3-stable、2-4-stable等等。以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
三、关于Merge request(pull request)
在团队开发中，我们作为项目代码管理者，我们要给小弟设置权限，设置保护分支。一般常用有两种管理方式。
1.团队中所有人都在master分支中开发，给其他人设置developer角色权限，设置保护分支，master所有人都可以push，但是只能master才能merge。然后需要建立一个稳定分支stable用于记录线上版本，因为在开发中可能master分支超前线上版本，这个时候就需啊哟一个分支来记录线上稳定版本.
2.团队中其他人都将项目git库fork到自己名下，然后clone到本地，添加上我们管理员名下git库的远程地址，这个时候他们作为developer的代码库就有了两个远程地址。我们设置下角色权限，他们只能够pull我们管理员的代码，但是不能进行push操作。那我们管理员怎么去同步其他developer的代码呢? 他们在完成一个分支feature branch的开发后，将feature branch push到他们自己的远程git库，然后发起merge request，申请将这个feature branch 合并到我们管理员的master分支，这个时候我们需要check out这个feature branch进行代码review，如果没问题则同意这次merge request，并删除这个合并请求分支。这样设置，其他developer可以更新我们管理员的代码，但是他们的修改不会直接影响到我们的代码，这样就能避免其他developer的错误操作导致项目出现不必要的Bug或者conflict。
