集中式工作流

工作方式

开发人员将master分支从中央仓库克隆到本地，修改完成后再推送回中央仓库master分支。

优点

不涉及分支交互操作。

缺点

• 不适合人员较多的团队，当人员10+时，解决开发人员之间的代码冲突会耗费很多时间。
• master分支因提交频繁会导致分支不稳定，不利于集成测试。

Tips：如何尽量避免产生冲突和不合理的提交历史？

开发人员在开发一个新功能之前，一定要在本地同步中央仓库最新代码，使自己的工作基于最新的代码之上；开发完成后，在提交新功能到中央仓库前，需要先fetch中央库的新增提交，并rebase自己的提交。这样做的目的是，把自己的修改加到中央仓别人已经提交的修改之上，使最终的提交记录是一个完美的线性历史，而不是环形，工作流举例如下图所示。

1. 开发人员A和开发人员B同时在某个时间拉取了中央仓库的代码。
2. 开发人员A先完成了自己的工作，并提交到中央仓库。
3. 开发人员B需要在本地执行git pull –rebase中央仓库的新提交，这时开发人员B的本地仓库就包含了开发人员A修改的内容，并在A的基础上增加了自己的修改。
4. 开发人员B将代码推送到中央仓库。