团队协作流程
问题——三个人，造同一辆车，怎么搞？
- 完全分工：三个人各写一部分代码，最后拼到一起
- 优：相当于流水线操作，我造车头，你造车尾，互相不冲突，貌似效率很高。
- 劣：首先，不容易整合到一块，后期的问题多; 其次，彼此交流势必会少，不符合AKA(all know all)的原则，团队成员的成长和能力提高必然受限，不符合初衷。
- 完全协作：三个人商量着写
- 优：每个人都会参与到所有的进程当中，可以共同进步。
- 劣：所有事情都三个人一起做，必然效率低
- So, 看起来只有折中，即有分工、有协作，那么具体怎么操作？
Github Flow
Github Flow是Github公司正在实践的非常简单的开发流程，整个开发的流程如下：
- 令master分支保持为一个稳定的可用的版本
- 进行开发的时候，从master分支创建新分支，新分支的名字要具有描述性（这样别人看名字，就知道这个分支在开发什么）
- 在2创建的分支中写代码、提交、push。
- 自己的这个部分开发得差不多了，就创建一个pull request, 让另外两个人审查代码，审查并修改完成后，与master分支合并
- 合并后立即部署
实际操作步骤：
- 首先，确认分工，认领自己的任务
- 从master创建一个自己任务的分支，比如，我要做微信公众号的接口，那就创建一个分支wechat
- 在wechat分支里面工作，和以前的工作一样，正常commit, push
- wechat功能全部搞定了以后，创建一个pull request，另外两个人审核代码，提出意见，进行修改。
- 修改到满意的版本后，合并到master
部署到服务器
这个流程既包含了分工（创建各自的分支），也包含了协作（Pull request审核代码）的过程。
- 比较简单易用，看起来可行性还可以。
Git Flow
- Git Flow是芝麻星任务卡片里面提示的协作流程，和Github Flow几乎一样，但是在各自的任务分支和master之间又多了一层develop。
- 也就是说，master是正式版，比较少，develop是beta测试版，可以经常更新。
- 觉得这个的好处是，保证了master的稳定，同时兼顾了开发的灵活性。
- 但我觉得我们人数太少（3人），而且开发的时间短（3周），所以觉得没必要再多搞一层develop，所以建议用Github Flow流程。