团队协作流程

[huijuannan]

问题——三个人，造同一辆车，怎么搞？

• 完全分工：三个人各写一部分代码，最后拼到一起
  • 优：相当于流水线操作，我造车头，你造车尾，互相不冲突，貌似效率很高。
  • 劣：首先，不容易整合到一块，后期的问题多; 其次，彼此交流势必会少，不符合AKA(all know all)的原则，团队成员的成长和能力提高必然受限，不符合初衷。
• 完全协作：三个人商量着写
  • 优：每个人都会参与到所有的进程当中，可以共同进步。
  • 劣：所有事情都三个人一起做，必然效率低
• So, 看起来只有折中，即有分工、有协作，那么具体怎么操作？

Github Flow

Github Flow是Github公司正在实践的非常简单的开发流程，整个开发的流程如下：

1. 令master分支保持为一个稳定的可用的版本
2. 进行开发的时候，从master分支创建新分支，新分支的名字要具有描述性（这样别人看名字，就知道这个分支在开发什么）
3. 在2创建的分支中写代码、提交、push。
4. 自己的这个部分开发得差不多了，就创建一个pull request, 让另外两个人审查代码，审查并修改完成后，与master分支合并
5. 合并后立即部署

实际操作步骤：

1. 首先，确认分工，认领自己的任务
2. 从master创建一个自己任务的分支，比如，我要做微信公众号的接口，那就创建一个分支wechat
3. 在wechat分支里面工作，和以前的工作一样，正常commit, push
4. wechat功能全部搞定了以后，创建一个pull request，另外两个人审核代码，提出意见，进行修改。
5. 修改到满意的版本后，合并到master
6. 部署到服务器

• 这个流程既包含了分工（创建各自的分支），也包含了协作（Pull request审核代码）的过程。
• 比较简单易用，看起来可行性还可以。

Git Flow

• Git Flow是芝麻星任务卡片里面提示的协作流程，和Github Flow几乎一样，但是在各自的任务分支和master之间又多了一层develop。
• 也就是说，master是正式版，比较少，develop是beta测试版，可以经常更新。
• 觉得这个的好处是，保证了master的稳定，同时兼顾了开发的灵活性。
• 但我觉得我们人数太少（3人），而且开发的时间短（3周），所以觉得没必要再多搞一层develop，所以建议用Github Flow流程。

Reference

• http://jeffkreeftmeijer.com/2010/why-arent-you-using-git-flow/
• https://help.github.com/articles/github-flow-in-the-browser/
• http://www.ruanyifeng.com/blog/2012/07/git.html

[xpgeng]

• 增补一个廖雪峰关于github多人协作的教程
• http://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013743862006503a1c5bf5a783434581661a3cc2084efa000