在上篇文章中,我谈到了我日常使用Git作为个人项目管理工具的一些基本用法。同时，我还简单地谈了一下使用Git作为个人项目管理工具的好处。但是，Git的强大威力只有在多人协作与大项目开发中才能真正体会到。它的分布式理念，灵活的分支机制，再加上多种错误应急措施，让我对它赞不绝口。

本文主要谈一下我在参与开源项目Cocos2D-X中学到的一些东西。

多人协作

首先，Cocos2D-X现在主要分为3个分支（v1,v2和v3），分别对应OpenGL ES1.0，OpenGL ES 2.0 OC style和OpenGL ES 2.0 C++11 style。目前，整个团队的重心放在v3分支上面。新功能的开发，bug的修复以及代码的持续改进基本上都基于v3分支在做。而v2分支主要是用来修复一些重大的bug。

谈到多人协作，肯定免不了要提到Github，这家伙现在可是程序猿们津津乐道的话题。不过国内访问Github的速度有点慢，有时候还访问不了，比较郁闷。国内的代码托管平台也比较多，推荐码云和Coding。

一个项目一般由一个组织或都者一个牛人发起，然后其他人可以通过fork+pull request的方式来给此项目贡献代码。参与者不仅仅局限于代码提交，还可以修复文档和注释，另外还可以提建议和反馈bug。另外这些代码托管平台一般还提供项目wiki的功能，这样代码和文档就更好地放在一起了。

采用这种方式进行软件开发，我认为有以下几点好处： 一、可以集众人之智慧，不断地改进软件代码，提高软件质量 二、每一份代码在合并进主仓库时，都会有人进行Code Review。这是一种非常好的软件工程实践 三、可以与jekins或者travis等持续集成工具结合，一旦有pr产生，CI服务器便会对代码进行构建并在构建结束时返回此次构建的状态。确保每一份代码在check in的时候至少编译正确。 四、可以与redmine等issue系统关联起来，让roadmap的制订，issue的管理，bug的反馈融合成一个有机整体，有效地帮助PM对项目进行把控。 五、能让程序员更加关心自己的代码。每一份代码在发PR之前，至少在本地由自己Review一遍，如果产生了bug，能及时有效地发现并解决之。 六、有完整的版本历史，可以方便地追踪错误代码的责任人，另外，使用git bisect也可以非常方便地定位一些非常隐秘的bug。

我很难想象，现在一个大型项目如果没有使用版本控制,持续集成工具和issue系统，它将如何能够良性发展，可能等待程序员的只有没日没夜地加班了。

Git的分布式

当我在没有网络的情况下面我也可以在本地提交代码，这是svn无法做到的。另外，任何一个人的代码，可以作为主仓库代码，可以被别人fork，也可以合并到其它人的代码里面去。Git的这种灵泛的特性允许我们把一个大型项目拆分成若干个项目组，每一个组fork一份代码，然后每个组的成员从组长那里再fork代码。组员的代码要提交到组长那里去审核，最后，当一个功能特性做完以后，再由组长提交pr到主仓库上去。此时，代码还可以被更高级别的人Review。

它同时也允许多人并行进行项目开发，并且各自独立提交修改。当要发PR的时候，可以先用git rebase -i来整理好log历史记录。一旦历史记录ok，就可以给主仓库发pr了。

Git让我变成一个更好的程序员

现在，任何一个non-trival的项目，我都会使用Git来管理并且同步到Github（或者Gitcaf、开源中国上）。我曾经做过一个外包小游戏，用了不到2周完成了。如果不是使用了Git，我想我肯定无法在这么短的时间内完成项目。因为，我的每一步正确的代码都会及时提交进版本库，而我的每一个想法都可以尽情地被testing而不用担心破坏已有的代码。

其次，我在学习一门新技术，比如OpenGL ES2.0和WebGL时，我会把我学习过程中的一些Demo都用Git管理起来，同时上传到相应的代码托管平台上面。这样做的好处是，下次我可以非常方便地找到我以前写的代码，及时温故和复查。

最后，Git提供了一种思维模式，即“小步快跑，大胆试错”的理念。通过不停地切分支，合并分支，最后项目在不断地往前推进，这种感觉真好！

关于Git命令行与图形化工具

我目前主要用Git命令行工具，我喜欢这种Geek-style。同时，我觉得使用比GUI方便。但是我也用SourceTree（windows下用tortoisegit）来做Code Review和冲突解决。命令行与GUI应该是统一的，没有必要排拆任何一方，能让自己的工作最高效的做事方法就是最好的。