git flow，git 工作流介绍【集合】

目前主流的代码版本管理工具有git, svn等，相比集中式的svn，分布式的git更受欢迎。然而正是由于 git 是分布式的，导致其灵活性太高，如果放任自由，结果肯定是一团乱麻，无法做到稳定发布、部署、回滚等。所以，git flow 是非常必要的。这里我们将列举一些主流的 git flow 供大家参考。。各位见仁见智吧。

集中式 git flow

集中式其实就是仿svn式流程，只使用一个仓库，一个分支，每次提交之前先同步远程仓库，提交历史为一条线，（尽量）没有分叉。

这种流程的要点是，要经常使用rebase。

git-workflow-svn-6.png

它的特点是：

1. 只有一个远程仓库
2. 只有一个master分支
3. pull 时带 --rebase 选项
4. 在push前，先pull

功能分支式 git flow

开发者在本地仓库创建功能分支，并将分支推送到远端，这样其他的开发者也能看到你的工作，并进行Code Review。

这种开发方式能够使用 Pull Request。

特点：

1. 只有一个远程仓库
2. 开发者自己创建分支
3. 分支应该定期推送到远端
4. 开发者可以通过远端看到彼此的进度
5. 可以Code Review

经典 git flow
功能分支是任何开发者可以创建任何分支并push到远端，而GitFlow则是严格的分支模型，以图说明：

git-workflow-release-cycle-4maintenance.png

也有这样描述的：

Git Flow2.jpg

太经典，就不细说了

Forking git flow

首先，有一个主远程仓库，然后，每个人都fork该远程仓库，从而每个人都有了自己的远程仓库，最后，每个人都可以 clone 主远程仓库，clone 自己的远程仓库，clone 其他人fork的远程仓库到本地，如下图：

git-workflows-forking.png

github 上开源仓库的主要流程就是这样。每个人在自己fork的仓库中push新分支，并向主远程仓库发起 Pull Request。这种方式的好处是，主远程仓库上很干净，而开发者自己fork的仓库可以随意地开分支、提交，并自己决定是否把工作成果请求同步到主远程仓库。
这是在分布式开发环境下的合理流程。
这里特别强调分布式开发环境，意指地理上分布（不同国家），时间上分布（不同时区），这样松散的合作方式，forking是最好的git flow模型了。
所以，公司内部项目就免了吧。

Github工作流

Understanding the GitHub flow

其实这是一种敏捷的功能分支流程，这里详列如下：

1. 令master分支时常保持可以部署的状态
2. 进行新的作业时要从master分支创建新分支
3. 在2新建的分支中本地提交
4. 在远端创建同名分支，并定期push
5. 需要帮助或反馈时，创建Pull Request
6. 让其他开发者Code Review，确认后合并到master
7. 合并到master后立刻部署