唱吧客戶端團隊的的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/