Git使用指南

標籤：自己   sgi   min   tab   ng-model   tar   ima   測試   分享   

不都是SCM代碼管理嘛，有很大區別嗎？很多svn老鳥都是抱著這樣的心態去學習git，然後無一倖免地陷入“查閱過很多資料，依然掌握不好”的困境，至少我們團隊是這樣的。

網上的資料確實已經很多了，卻沒有把整個知識結構串起來。通讀《git權威指南》是可行的，只是大家都急著用，沒那耐性。我這裡熬一碗雞湯，整理供大家享用。

一、安裝

伺服器端不展開，因為主要面向搬磚的碼農。

用戶端可參見大神 廖雪峰 的Git教程-安裝git

需要特別說明的是，在windows中，msysgit才是真正的git用戶端，烏龜tortoisegit只是個介面。mercurial和sourcetree也是類似道理。

二、本地版本庫

又見 工作區和暫存區

這裡容易是初學者容易踩坑的地方，代碼只提交到本地版本庫，卻沒有推送到遠程版本庫。（其實是選型的人的反人類設定吧，用分布式的工具去做集中式的管理。）

svn是本地-遠程兩層的結構，而git則是工作區-本地-遠程三層的結構。

在用戶端看的見到的源碼檔案是工作區，提交到的是本地版本庫，本地版本庫的修改如果不推送，就是單機自己玩，不會影響其他人。

三、相關命令和衝突合并

命令方面資料很健全，我就不重複造輪子了。見上文的Git教程。

命令的查閱很流行這種叫Cheatsheet（考試作弊的小抄嗎？）速查手冊，也是一搜一大把～

比如 http://ndpsoftware.com/git-cheatsheet.html 清晰地指出從哪個區到哪個區對應的命令是什麼～

又比如，圖示說明了遇到各種情境應該怎麼辦。

至於衝突，都是發生在跨分支或跨庫的修改。比如，工作區的修改未commit而pull遠端更新時會報錯（要先commit），本地庫push發現遠程庫有其他人提交時會報錯（要先pull並在本地解決衝突），暫存區取回stash pop時可能發生衝突。

而當合并發生衝突需要手動解決時，svn老鳥肯定是懵逼的，三路對比合并，哪個打哪個啊。。。這是因為，在svn中只有“我和中央庫”的衝突，而git中卻是“我和他”的衝突。

所以在git中做合并有三個源：base是分支的共同祖先，local是本地倉當前分支，remote是要從這個分支合過來，output當然就是合并結果的預覽啦。

詳見 對於解決 Git 的 Merge Conflict 你有哪些經驗和技巧？

四、命令列or圖形介面？

兩者沒有本質區別，圖形介面最後也還是觸發命令。直接用命令列能更好理解整個操作的過程。

圖形介面則操作方便。但新手一定要對圖形介面中的參數保持敏感，可能多勾了選項結果就完全不一樣，比如--force。。。

五、分支管理

查閱過很多git分支管理的資料，依然用得不好，直到踩過若干個月的坑。。。

git的發源是開源系統，思想是分布式、去中心化，用svn的集中式管理是很容易踩坑的。

首先，svn是針對檔案內容的對比，而git是針對檔案增量和提交時間的對比，多人的頻繁的衝突合并極容易發生錯誤。

其次，git的去中心化思想認為每個開發人員都是熟練的負責任的。而事實上不是的，如果團隊裡有一兩個“流氓”，遇到衝突沒有細看，直接--force或use mine，測試會抓狂的，然後開發和專案經理都會抓狂的～

然後最後，你便會質疑：為什麼不用svn啊？git跟svn沒什麼區別啊，還更難用！

且看看開源項目對git是怎麼用的。 Git使用規範流程 開發人員先fork複製出自己的庫（遠程），然後一系列的開發（本身也可以有分支管理），push上自己的遠程庫後，再pull request提交給管理員review和合并。而開源項目的發布，是有stable和nightly update等不同的發布版本。

回過頭來看，公司團隊裡的項目要怎樣管理git的版本和分支呢？

 git flow 便是最完整最科學的分支管理模型了。

這裡有四點血淚經驗要謹記：

1.不要吝嗇開分支，git開分支的代價很小。

2.合并是容易出事的環節，要讓負責任的熟手來把關。

3.以feature劃分開發分支是非常好的思維方式，把相互依賴的內容放在一起、把不相關的內容隔離開、讓“這個功能暫時不上”這種需求變更變得可行。

4.分支是活的、會變動的，標籤tag才是一個確切的版本。

 

至此，使用git做源碼管理的項目和團隊足以運作起來而且可以避開大部分的坑。要用得更溜的話可以繼續精修patch、rebase、revert、--fast-forward、cherry pick等更高階的用法。

最後彩蛋：老司機溫馨提醒，請把eclipse專案檔、編譯後檔案（檔案夾）加入.gitignore檔案，這個問題在svn就存在了～

另一篇參考：GIT版本團隊內部操作規範 

Git使用指南