第三章(进阶2) 了解基于Git的协同工作流
我无意于重复已经存在的教程信息，只准备简单列出本次培训中各位所需要知道的精简信息。 如果你有兴趣，请移步阅读资料中的超链接，更加系统性地进行学习。
要流畅阅读本章，你应该对 第三章:多人协同开发 和 第三章(进阶1):干净的仓库历史 有较好的理解。
-
本章你将了解到各种Git工作流，即如何科学地使用Git进行多人协同工作。
-
你将学习到一个新的指令
git tag。
中心化工作流
这个观点我们在之前就已经提到过了，它也是Git的基础运作方式：
多个开发者拥有自己的本地仓库、自己的本地分支和一些本地-远程分支(如master分支)。每个开发者在各自的仓库和本地分支上进行开发，最终通过本地merge、rebase等方法与远程分支建立练习，推送到中心仓库并暴露这些更改给所有人。
开发者需要通过fetch等指令定期拉取这些变更，从而完成协同工作。(当然，这种工作方式会导致非常多的merge和conflict solve问题)。
版本化
开发者每次提交也许只是添加了几个新功能或是完成了几个页面，那怎么判断这个工程可以向外发布了呢？
让我们先切换到准备对外发行的分支，使用git tag来标记当前提交为可对外发行的版本：
git tag -a <版本号> -m <tab message>，如git tag -a v1.0 -m "first release"。
你的仓库历史出现一个tag标记：
将该打了标签的分支推送到远程仓库，以Github为例
我们常说的——“你去Github下一个代码啊”，指的一般就是下载一个发行版，而不是直接git clone一份代码(尽管这在某些时候等价于下载一个发行版)。
Git Flow工作流
阅读资料：
以上几篇文章已经很好的讲述了Git工作流的工作方式，如果你对如何科学开发有兴趣，任选一篇仔细阅读即可。为了避免数据的丢失，我做了一些备份工作：备份资料
如上图所示，其大致思路如下：
- 存在两个恒定的分支
master和develop分支。master分支只负责版本化的commit记录，而开发者在develop分支上持续进行开发。 - 当有新功能要加入时，从
develop分支上分出功能分支feature_x，新功能完成后再合并到develop分支上。 - 当发行版发现一些恶性bug、需要进行热修复(hotfix)时，从
master分支开出一条热修复分支，修复完成后合并到master(同时更新一个新的发行版)和develop分支。 - 当
develop分支准备发行一个新的版本时，开出一个预发行分支pre_release，在这个分支上进行测试和bug修复，然后合并到master(同时更新一个新的发行版)和develop分支。 - 从
develop上开出的功能分支统统进入一个叫做发布循环的队列中，一旦当开发者觉得可以交工了，向develop分支推送(相应的可能会被推送到预发行分支pre_release)之后，该功能分支应当被【冻结】，除非有新的功能升级需求或bug修复需要，才能再进行改动——此时需要再从develop分支拉回某些变更完成同步，修正bug或完成需求后，等待下个发布循环再推送到develop上。