Git的四种工作流

图片及内容均引用自「简单的代码提交，还能玩出这么多花样？」

学习一下Git的四种工作流

集中式工作流

结构示意图

分支效果图

模式简单，可以理解为最基本的方式

功能分支工作流

在项目体量变大时，集中式会出现较多 冲突，此时使用feature分支便具有较强意义。

分支效果图

上述并没有考虑feature分支合并后的bug更正。master分支仍可能存在热修。

Gitflow 工作流

该工作流是 Vincent Driessen 基于开发实践总结的一套 Git 分支管理的流程和规范，此处简单记录。

Gitflow的关键是为不同分支指定来特定角色，包括master、开发、功能、预发布和维护，定义各分支允许的操作类型，以及相互的交互方式。具体的

• master
  可以直接部署的、稳定的版本。不能在该分支修改代码，从其他分支合并合并。
• develop
  主开发分支，包含所有要发布到下一个release的代码，由feature分支合并。
• features（临时分支）
• pre-release（临时分支）
  基于develop分支创建，经过测试人员充分测试后合入master和develop。也就是beta版了吧？
• hotfix（临时分支）
  在生产环境发现需要紧急修复的Bug时，创建hotfix分支，经过充分测试后合并入master合入develop。

分支效果图

Forking工作流

开源场景中，Forking工作流可以作为上述集中开发的补充。

Forking工作流体现了项目作者和贡献者的关系，结构示意图如下

增加了两者间fork、pull request的关系。这里的fork是远程仓库间的fork，贡献者fork仓库作者的代码到自己的远程仓库，然后才是clone、pull、push之类的修改流程。贡献者可以选择对原作者发起pull request。

题外：pull request ：request the official repo owner to pull some changes from your own repo. 毕竟不能push到作者的仓库。参考Why is a git ‘pull request’ not called a ‘push request’?