介绍

Git 是当今最常用的版本控制系统。Git 工作流是关于如何使用 Git 以一致且高效的方式完成工作的秘诀或建议。因为有分支的存在，才构成了多工作流的特色。在项目开发中，多人协作，分支很多，虽然各自在分支上互不干扰，但是我们总归需要把分支合并到一起，而且真实项目中涉及到很多问题，例如版本迭代，版本发布，bug 修复等，为了更好的管理代码，需要制定一个工作流程。

集中式工作流

熟悉SVN的都知道，SVN是集中式仓库，svn 的开发协作流程就是典型的集中式工作流，不同的开发同学需要依次将本地的修改提交到服务器，如果有冲突就先解决本地的冲突再提交，这个过程中远端的服务器就像是一个集中管理者，管理着所有人的代码提交。

而在Git下也有类似的集中式工作流：

每个开发人员将远程仓库的代码 clone 下来变成了属于自己的本地仓库，提交代码时先提交至本地仓库，然后再推送到远程仓库。
这种模式相比 SVN 只是多了一个本地仓库而已。

功能分支工作流

集中式工作流有一个很大的问题，随着团队内人员不断增多，大家每一次提交代码都可能会遇到冲突，提交代码一分钟解决冲突一小时。
功能分支工作流，这种工作方式是以集中式工作流为基础，再为不同功能开发分配单独的功能分支来进行的；这种工作流的主干分支仍然是 master 分支，但是开发者在进行日常需求开发时不能将代码直接提交到 master 分支上，一般是为特定的需求新建一个功能分支，并且取一个具有描述性的名字，例如：feat-personal-page、issue-#1702，描述性的名称可以让其他开发者快速地明白这个功能分支的主要作用，提高不同开发者之间的协同效率。相比于集中式工作流，分支工作流的历史看起来更加简洁、合理，让不同功能的开发进行隔离，避免不同功能代码之间产生不利的影响。

每个开发人员关注于自己的分支，需要提交代码时直接提交到本地库的功能分支，在合入到master分支前通常会拉取最新的代码，如果有冲突先在本地解决好冲突，解决完提交 PR/MR 申请将功能分支合入master分支。
PR/MR 操作给项目带来的益处有两点：1、code review2、讨论代码的公共平台
前者是每次 PR 操作发生时会通知相关者来检查待合并的代码，在检查过程中即完成了对代码的检视，这个过程保障了 master 分支上的已合并代码的健壮性；后者则是因为每次 PR 都会有一个 PR 详情主页，每一个开发者都可以针对代码的实现提出自己的意见，使得讨论代码变成更加便捷高效，且为代码变更回顾提供了可能。
注意：Pull Request 和Merge Request 本质上都是合入代码，只是站在不同角度有不同的说法而已。
在Github上叫Pull Request ，在Gitlab上叫Merge Request。

git flow工作流

master和develop分支

gitflow一共有5种分支，其中有2个永久的分支，分别是master和develop分支。

master分支只存放历史发布(release)版本的源代码。各个版本通过tag来标记。上图里的v0.1和v0.2就是tag。
develop分支则用来整合各个feature分支。开发中的版本的源代码存放在这里。

feature分支

每一个特性(feature)都必须在自己的分支里开发，feature分支派生自develop分支。
当feature开发完毕后，要合并回develop分支。feature分支永远不会和master分支打交道。

release分支

release分支不是一个放正式发布产品的分支，你可以将它理解为“待发布”分支。
我们用这个分支干所有和发布有关的事情，比如：

1. 把这个分支打包给测试人员测试
2. 在这个分支里修复bug
3. 编写发布文档

所以在这个分支里面绝对不会添加新的特性。
当和发布相关的工作都完成后，release分支合并回develop和master分支。
单独搞一个release分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。

hotfix分支

一个项目发布后或多或少肯定会有一些bug存在，而bug的修复工作并不适合在develop上做，这是因为

1. develop分支上包含还未验证过的feature
2. 用户未必需要develop上的feature
3. develop还不能马上发布，而客户急需这个bug的修复。

这时就需要新建hotfix分支，hotfix分支派生自master分支，仅仅用于修复bug，当bug修复完毕后，马上回归到master分支，然后发布一个新版本，比如v0.1.1。
同时hotfix也要合并回develop分支，这样develop分支就能享受到bug修复的好处了。

git flow 工作流是目前比较很成熟的方案，它的优点有：
1、发布迭代流程更顺畅
2、使得代码有了更加严谨的项目结构，方便定位排查问题
大型的项目 / 迭代速度快的推荐使用这种工作流程

forking工作流

是以 Github 为代表的一种代码协作方式，开发者通过克隆（fork）源仓库进行编写代码，一旦完成会发起 ，源仓库作者可以选择是否接受该 PR。
fork 操作是在个人远程仓库新建一份目标远程仓库的拷贝，操作很简单，比如 github 上在项目的主页点击 fork 按钮即可。

主要采取 fork + pull request 的模式进行协作，主要用于开源项目。

总结

• 集中式工作流可以说是 git 工作流的基础，初学者可以无缝地从 svn 的模式切换到 git 的模式。
• 功能分支工作流在集中式的基础上又引入了功能分支，灵活地利用了 git 的分支特性，功能分离 / PR 优化了日常工作的效率。
• gitflow 工作流则是为大型项目的迭代过程服务的，指定了一个严格的分支模型，使得迭代流程更加顺畅。
• forking 工作流则是开源项目的首选，想要为开源项目做贡献就必须要懂得这种工作流！

参考链接

https://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://segmentfault.com/a/1190000006194051
https://blog.csdn.net/qq_32452623/article/details/78905181
https://www.cnblogs.com/JerryMouseLi/p/12557693.html
https://xw.qq.com/cmsid/20210124A03RQW00?ADTAG=baidutw
https://zhuanlan.zhihu.com/p/347918608