之前开的坑来补。
如何利用 Git 的团队协作是个问题，处理不好会让工作事倍功半。
我在学习的过程中了解到了4种 Git 团队协作的方式。
1.中心化工作流
2.基于功能分支的工作流
3.Gitflow 工作流
4.Fork 工作流
中心化工作流
中心化工作流将中央仓库作为项目中所有修改的唯一入口。这种工作流不需要 master 之外的其他分支。
如何工作
开发者将中央仓库 clone 到本地后开始工作。在他们的本地仓库中，可以修改文件和提交更改，但是，所有新的提交都保存在本地，和中央仓库完全隔离。开发者可以将 upstream 的同步推迟到他们方便的时候去做。
管理冲突
在开发者发布功能之前，需要先 fetch 更新到最新到中央仓库，在它们之上 rebase 自己到更改。 这样的优点是可以留下完美的线性历史。
这套协作方式对于 SVN 的使用团队来说很棒，但是没有用到 Git 分布式的优点。
Feature 分支工作流
当你熟练使用 Git 之后，在你的开发流程中添加功能分支是一个非常能促进团队协作的方式。
这种工作流的好处是，多个开发者专注自己的功能而不会打扰中央仓库。还能保证 master 分支永远不会包含质量有问题的代码，给持续集成环境带来了很大好处。
封装功能的开发方式使得 Pull Request 的使用更加方便。它可以在开发者在功能并入项目之前一起参与讨论，提出问题，或者寻求建议。
如何工作
Feature 分支工作流同样使用中央仓库的概念，master 分支代表官方的项目历史。开发者每次进行新的工作时，创建一个新的分支，该分支名称应为描述功能或者针对某一 issue 。
feature 分支也应该被推送到中央仓库。这使得你和其他开发者共享这个功能，而又不会改变官方代码。
Pull Request 是分支工作流里非常便利的工具，有人如果完成了一个功能，他们不会立刻并入master。他们将 feature 分支推送到中央仓库发布一个 Pull Request 。这样可以在并入主代码库之前让所有其他开发者审查代码。Pull Request 也是一个讨论板块，任何人遇到问题需要帮助时可以发起一个 Pull Request 让其他开发者看到。
GitFlow 工作流
GitFlow工作流相比功能分支工作流没有增加新的概念，它给不同的分支制定的不同的功能，严格定义了它们应该怎样以及何时进行交流。
开发分支
对于一个开发人员来说，开发分支是打交道最多的分支。每增加一个功能，就在开发分支的基础上新建一个功能分支，每当功能开发完成时，它会杯合并会开发分支。功能分支 永远不应该跟 master 交互。
发布分支
一旦 开发分支的新功能开发到一定程度（deadline 或者 其他原因），你可以从 开发分支 fork 出来一个分支发布。这个分支的创建开始了下一个发布周期。只有和发布有关的工作应该在词分支上进行。
发布完成后，发布分支将合并进 master，并打上版本号标签。另外也应该合并回 develop ，后者可能在发布启动后又有了新的改动。
通常使用一个专门的分支来准备确保一个团队修复当前发布的功能，其他团队可以开发下一个发布的功能。
维护分支
维护分支 （hotfix）用来紧急给产品的发布打上布丁，这是唯一可以从 master 上 fork 的分支。修复完成后，它们应该被并入 master 和 develop 分支。
实际的工作流程，则需要根据上面规则和实际情况进行详细的规划。
Fork 工作流
Fork 工作流不同与其他几个工作流。这个工作流可以让每个开发者都拥有一个服务端仓库。也就是说每个贡献者都有两个Git仓库，一个开放的服务端仓库，和私有的仓库。
Fork 工作流的主要有点在于代码可以轻易的整合进项目，而不需要每个人都推送到单一的中央仓库。开发者推送他们自己的服务端仓库，只有项目管理者可以推送到官方仓库。这使得管理者可以结束任何开发者的提交，却不需要给他们中央仓库的权限。
在工作项目中，本源规定了一套 Git Flow 工作流，后来因为开发者只有我一个人（partner在比较闲的时候时不时会来贡献几个功能），并且没有 中央代码库 的权限。所以后来就逐渐转变成了 Fork 工作流。
相比前三个工作流，Fork 工作流使用起来更简单，且最安全。因为贡献代码的人并不干扰中央仓库，只通过 Pull Request 来和中央代码库进行交互，最适用的场景就是开源仓库，和松散型的开发团队使用。
以上就是在和 Partner 寻找有效的工作方式时，学习到的 Git 团队工作流程。以后如果遇到其他新奇的工作流程会再补充更新。