目前主流的代码版本管理工具有git, svn等，相比集中式的svn，分布式的git更受欢迎。然而正是由于 git 是分布式的，导致其灵活性太高，如果放任自由，结果肯定是一团乱麻，无法做到稳定发布、部署、回滚等。所以，git flow 是非常必要的。这里我们将列举一些主流的 git flow 供大家参考。。各位见仁见智吧。
集中式 git flow
集中式其实就是仿svn式流程，只使用一个仓库，一个分支，每次提交之前先同步远程仓库，提交历史为一条线，（尽量）没有分叉。
这种流程的要点是，要经常使用rebase。
git-workflow-svn-6.png
它的特点是：
- 只有一个远程仓库
- 只有一个master分支
- pull 时带 --rebase 选项
- 在push前，先pull
功能分支式 git flow
开发者在本地仓库创建功能分支，并将分支推送到远端，这样其他的开发者也能看到你的工作，并进行Code Review。
这种开发方式能够使用 Pull Request。
特点：
- 只有一个远程仓库
- 开发者自己创建分支
- 分支应该定期推送到远端
- 开发者可以通过远端看到彼此的进度
- 可以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工作流
其实这是一种敏捷的功能分支流程，这里详列如下：
- 令master分支时常保持可以部署的状态
- 进行新的作业时要从master分支创建新分支
- 在2新建的分支中本地提交
- 在远端创建同名分支，并定期push
- 需要帮助或反馈时，创建Pull Request
- 让其他开发者Code Review，确认后合并到master
- 合并到master后立刻部署
网友评论