转载

唱吧客户端团队的 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 bug or Bug 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？

正文到此结束