唱吧客户端团队的的Git实践

写在前面：我对Git的理解实在有限，也无力全方位的比较SVN和Git的优缺点。只是从Git初级使用者的角度，分享一下过去一年使用Git的感受和经验。更希望得到更多的指导和反馈，请各位读者不吝赐教。

唱吧一直使用SVN作为SCM，在经历了几次绝望的merge和混乱的版本迭代后，Git作为更适合我们开发模式的SCM工具开始被提及。

使用Git作为SCM工具基于以下的考虑：

• SVN真的太慢了，repo太大了，而且越来越糟糕
• SVN的提交太不灵活，导致很多commit的粒度过大且不明确
• Branching的成本实在太高，Merge的过程太痛苦
• Git的配套工具甩开SVN一个段位，至少Mac平台上是这样儿

之前做IndieBros Studio这个二人团队时，由于只有我一个工程师，Git对我来说就是单机游戏。作为推动者自己一定要尽可能把所有的情况和风险考虑清楚，并随时充当救火队员的角色，放好Buff是关键。

我们从SVN切换到Git的过程是这样儿的：

• 最开始一个月，我自己使用git-svn，单机玩得爽
• 接着号召大家用git-svn一起玩，基本无效
• 后来开始威逼利诱manager一起玩，有点效果
• 一起玩了2个月之后，借着6.0大改版的时机，找了个VM做了个bare repo，把iOS SVN仓库迁移了过去
• 4个半月后，6.0 release，Android团队进来玩
• 1个月后，Gitlab的使用提上日程，目前正在进行中

介绍下唱吧客户端团队的branching model:

• Git-flow的简化版
• Master分支作发布，每个release打一个tag
• 日常开发在dev分支进行，
• 与业务无关的重构和改进单独开feature branch
• 使用feature branch作code review
• 线上问题及小版本使用hotfix分支，再merge回master和dev
• 同一分支内，建议使用git-rebase以保持线性提交历史
• 使用Gitlab后，保持现有的模型并加大code review的比重；避免folk模型以保持简单

再来看看我们遇到过的问题：

• 本地repo丢了很多commit(事后发现是rebase掉了)，后经过git-reflog找回
• Branch model使用混乱，导致一个release缺少了一个feature branch的部分commit，重新发版
• 本地未提交就使用了git checkout .，无力回天
• 误删掉了所有remote repo，从本地重新push
• 粒度过大的commit，commit log是Fix bugorBug fix

下面是我个人使用Git的经验，即使在团队内部也只是作为建议，欢迎大家讨论：

• 保持较小的提交粒度，一个提交只做一件事情
• 提交记录一定要明确，避免大量重复及语焉不详
• 多开本地分支，多使用git stash，开remote branch需要跟大家说明
• 确保团队所有成员对branch model有相同的理解
• Merge feature branch时请不要使用fast forward
• git rebase有助于保持线性的提交历史，建议适当使用
• 对于未提交的本地commits，可以使用rebase -i重写提交历史，以保证提交合适的提交粒度与清晰的提交记录
• 永远不要改变已经推送到remote的提交历史，这会给团队造成很大麻烦（不要使用rebase及reset）
• 慎用git-cherry-pick，但有时这是最好的选择
• 在本地仓库多尝试，只要提交过的记录，基本就没有任何风险
• 遇到困难时，man git、git reflog是好帮手

Git的好处和坏处都是灵活：Git带给我们更灵活更合理的开发模型和节奏，也带来了更高的学习和使用成本。随着时间的推移，好处是递增的，成本是 递减的，总体还是获得了很大的效率提升。在我看来，使用Git最重要的就是搞清楚并找到最适合团队的branching model，推荐一个我认为最好的教程：Git Tutorial from Atlassian。

各位也来分享一下，你的团队如何使用Git？

来自：http://www.iwangke.me/2015/02/08/Git-in-action-at-ChangBa/