Git工作流概述

集中式工作流

基于master分支开发

流程：

创建origin/master分支
协作开发者A、B把origin/master 分支clone到本地
协作开发者A、B在本地master分支进行开发
A开发完push到远程master分支
B开发完push到远程master分支

冲突处理

push时本地代码与远程master有分歧时推不上去，用git pull --rebase origin master把远程master的代码与本地代码进行合并同步，如果merge的过程中存在CONFLICT，解决完conflict再push到master。

重点

每次开发前都从origin/master 分支先pull一下
提交之前也 git pull --rebase

功能分支工作流

功能分支工作流开发工工作在特性分支开发，在最终合并到master之前不会影响master分支的代码，保证了master分支可以作为一个稳定的可发布版本。

流程

确定开发的功能后以master为基础创建一个功能分支例如 dev git checkout -b dev master
在特性分支上进行开发，开发之后push到中央仓库的功能分支，其他人也可以提交到该功能分支
该功能分支开发完成之后，提交一个pull request请求合并到master，项目成员进行讨论

pull request合并后该分支删除

git checkout master
git pull
git pull origin dev
git push

重点

功能分支与master主分支在同一个中央仓库
pull request进行code review
互不影响，多个功能同时开发
合并分支的时候，加上 no-ff 参数

Git flow 工作流

Gitflow 工作流，扩展了集中式工作流与功能分支工作流。包含开发分支devleop，特性分支 feature-xx，发行分支release-xx，维护分支 master，修复分支 hotfix

流程

项目创建的时候同时创建master和develop分支
项目成员clone把项目到本地
开发feature的时候以develop进行checkout
git checkout -b develop origin/develop
feature 开发完后发起 pull request合并到到develop
版本开发完成后准备发行，以develop创建一个release-xx发行分支
release发行完成，把release-xx合并到维护分支master，并打上tag标签
发行后修改bug，以master分支checkout一个hotfix-xx分支，修改后合并到master分支，同时要合并到develop分支。

重点

各分支的意义
- feature (多个) 主要是自己玩了，差不多的时候要合并回 develop 去。不与 master 交互。
- develop (同时间一个) 主要是和 feature 以及 release 交互
- release (同时间一个) 总是基于 develop，最后又合并回 develop。当然对应的 tag 要合并到 master 分支，生命周期短，仅是为了发布程序
- hotfix (同一时间一个) 总是基于 master，并最后合并到 master 和 develop。生命同期较短，用来修复 bug 或小粒度修改发布
- master (仅一个) 关联 tag 和发布
特性分支都是基于开发分支develop
发行分支创建好之后，要修改部分内容要往release分支合并
发行后的维护需要从master 进行checkout

Forking 工作流

把中央仓库fork到自己的代码仓库，在自己的代码仓库开发，完了之后提交pull request 合并到中央仓库的主分支

流程

fork
git remote add
pull request

重点

Forking工作流的一个主要优势是，贡献的代码可以被集成，而不需要所有人都能push代码到仅有的中央仓库中。
开发者push到自己的服务端仓库，而只有项目维护者才能push到正式仓库。

GitHub Flow

GitHub Flow 推荐做法是只有一个主分支 master，团队成员们的分支代码通过 pull Request 来合并到 master 上

GitHub Flow 模型简单说明

只有一个长期分支 master ,而且 master 分支上的代码，永远是可发布状态,一般 master 会设置 protected 分支保护，只有有权限的人才能推送代码到 master 分支。
如果有新功能开发，可以从 master 分支上检出新分支。
在本地分支提交代码，并且保证按时向远程仓库推送。
当你需要反馈或者帮助，或者你想合并分支时，可以发起一个 pull request。
当 review 或者讨论通过后，代码会合并到目标分支。
一旦合并到 master 分支，应该立即发布。

特色之 Pull Request

GitHub Flow 最大的特色就是 Pull Request 的提出，这是一个伟大的发明，它的用处并不仅仅是合并分支，还有以下功能：

可以很好控制分支合并权限。
分支不是你想合并就合并，需要对方同意呐
问题讨论或者寻求其他小伙伴们的帮助。
和拉个讨论组差不多，可以选择相关的人参与，而且参与的人还可以向你的分支提交代码，可以说，是非常适合代码交流了。
代码 Review 。
如果代码写的很烂，有了 pull request 提供的评论功能支持，准备好接受来自 review 的实时吐槽吧。当然你如果写的很棒，肯定也能被双击666的。

特色之 issue tracking 问题追踪

日常开发中，会用到很多第三方库，然后使用过程中，出现了问题，是不是第一个反应是去这个第三方库的 GitHub 仓库去搜索一下 issue ，看没有人遇到过，项目维护者修复了没有，一般未解决的 issue 是 open 状态，已解决的会被标记为 closed。这就是 issue tracking。

如果你是一个项目维护者，除了标记 issue 的开启和关闭，还可以给它标记上不同的标签，来优化项目。当提交的时候，如果提交信息中有 fix #1 等字段，可以自动关闭对应编号的 issue。

Gitlab flow

集百家之长，推荐使用

团队配合

一个版本划分为主线和辅线，A负责主线开发，B负责辅线和线上bug修复，下个版本互换，A负责辅线和线上bug修复,B负责主线开发