git开发场景
3. 基于git的合作开发
对于酷讯来说，当我们采用了Git，如何进行合作开发呢？ 具体步骤如下：
3.1 获取最新代码
酷讯会准备一个中心git代码库。首先，我们将整理好的代码分模块在git中心库中建立git库。并将文件add到中心库中。 接下来，开发者通过git-clone将代码从中心库clone到本地开发环境。
对于较大的项目，我们还建议每个组选择一个负责人，由这个负责人负责从中心库获取和更新最新的代码，其它开发者从这个负责人的git代码库中clone代码。此时，对开发者来说，这个负责人的git库就是中心库了。
3.2 开发者在本地进行迭代开发
当用户将代码clone到本地后， 就可以进行本地的迭代开发，建议用户不要在master分支上开发，而是建立一个开发分支进行开发。 在本地开发中，用户可以随意的创建临时分支，随意commit。
3.3 开发者请其它同事进行code review
当本地开发完毕，可以请其它同事进行code review。过程为：
1. user2通通过git-pull命令，将开发者(user1)的开发分支（dev）pull到user2本地的一个tmp分支，并切换工作分支到该分支上进行code review。
2. 完成code review后， user2切换回其原有开发分支继续开发，并告知user1已经修改完毕。
3. User1将user2的tmp分支git-pull到本地tmp分支，并和dev分支进行merge。最终得到一个code review后的dev分支。
当然，user2也可以直接坐在user1旁边在他的代码上进行review。而不需要走上述步骤。（图中第7步，不是git-pull,而是直接在dev分支上和user1边review边modify）
3.4 和中心库进行代码合并
使用过CVS的人都知道， 在commit之前，都要做一次cvs update，以避免和中心库冲突。Git也是如此。
现在我们已经经过了code review， 准备向中心库提交变化了， 在开发的这段时间，也许中心库发生了变化， 因此，我们需要在向中心库提交前，再次将中心库的master分支git-pull到本地的master分支上。并且和dev分支做合并。最终，将合并的代码放入master分支。
如果开发过程提交日志过多，可以考虑参照2.10节的介绍做一次git-reset。
此外，如果发现合并过程变化非常多， 出于代码质量考虑，建议再做一次code review
3.5 提交代码到中心库
此时，已经完全准备好提交最终的代码了。 通过git-push就可以了。
3.6 合作流程总结
大家可以看到，使用git进行合作开发，这一过程和CVS有很多相似性，同时，增强了以下几个环节：
1. 开发者在本地进行迭代开发，可以经常的做commit操作且不会影响他人。 而且即使不在线也可以进行开发。只需要最后向中心库提交一次即可。
2. 大家都知道，如果CVS管理代码，由于我们会常常做commit操作。但是在commit之前cvs update时常会遇到将中心库上的其它最新代码checkout下来的情况，此时，一旦出现问题，就很难确认到底是自己开发的bug还是其它用户的代码带来了影响。 而使用git则避免了用户间的开发互相影响。
3. 更有利于在代码提交前做code review。 以往用cvs， 都是代码提交后才做code view。如果发生问题， 也无法避免服务器上有不好的代码。 但是用git， 真正向中心库commit前，都是在本地开发，可以方便的进行code review， 然后才提交到中心库。更有利于代码质量。而且， 大家应该可以感到，使用git的过程中，更容易对代码进行code review，因为影响因素更小。
4. 创建多分支，更容易在开发中进行多种工作，而使工作间不会互相影响。 比如user2对user1的代码进行code review时，就可以非常方便的保留当时的开发现场，并切换到user1的代码分支，在code review完毕后，也可以非常方便的切换会曾经被中断的工作现场。
诚然，带来这些好处的同时，确实也使得操作比CVS复杂了一些。但我们觉得和前面所能获得的好处相比，这些麻烦是值得的。 当大家用惯了之后会发现，这并不增加多大的复杂性， 而且开发流程会更加自然。
