隔離開發(fā)，提交審核

如何對團(tuán)隊中的新成員的開發(fā)進(jìn)行審核呢？在Git服務(wù)器上可以實現(xiàn)用戶自建分支和自建版本庫的功能， 這樣團(tuán)隊中的新成員既能將本地提交推送到服務(wù)器以對工作進(jìn)行備份， 又能夠方便團(tuán)隊中的其他成員對自己的提交進(jìn)行審核。

審核新成員提交時，從其個人版本庫或個人分支獲�。╢etch）提交，從提交說明、代碼規(guī)范、編譯測試 等多方面對提交逐一審核。審核通過執(zhí)行 git merge 命令合并到開發(fā)主線中。

對合并更好的支持，更少的沖突，更好的沖突解決

因為Git基于對內(nèi)容的追蹤而非對文件名追蹤，所以遇到一方或雙方對文件名更改時， Git能夠很好進(jìn)行自動合并或提供工具輔助合并。而SVN遇到同樣問題時會產(chǎn)生樹沖突， 解決起來很麻煩。

Git的基于DAG（有向非環(huán)圖）的設(shè)計比SVN的線性提交提供更好的合并追蹤， 避免不必要的沖突，提高工作效率。這是開發(fā)者選擇Git、拋棄SVN的重要理由。

保證已修復(fù)Bug不再重現(xiàn)

以為創(chuàng)建完畢里程碑標(biāo)簽（tag）便完成軟件版本的發(fā)布是有風(fēng)險的， 往往會由于之前的版本（維護(hù)版本）中的一些 Hotfix 提交沒有合并到新版本而造成已修復(fù)問題在新版本中重現(xiàn)。

Git分支和合并追蹤可以解決這個問題。例如用 maint 分支跟蹤新的發(fā)行版， 當(dāng)確定里程碑tag v1.6.4 為新發(fā)行版時，在 maint 分支執(zhí)行如下命令以切換到新發(fā)行版：

    $ git checkout maint $ git merge --ff-only v1.6.4

如果合并成功，代表發(fā)行版 v1.6.4 包含了所有前一個發(fā)行版的提交。 反之說明前一個發(fā)行版某個或某些Hotfix提交尚未合并到新發(fā)行版中。

版本庫的安全性

SVN版本庫安全性很差，是管理員頭痛的問題。

● SVN版本庫服務(wù)器端歷史數(shù)據(jù)被篡改，或者硬盤故障導(dǎo)致歷史數(shù)據(jù)被篡改時， 客戶端很難發(fā)現(xiàn)。管理員的備份也會被污染。

● SVN作為集中式版本控制系統(tǒng)，存在單點故障的風(fēng)險。備份版本庫的任務(wù)非常繁重。

Git在這方面完勝SVN。首先Git是分布式版本控制系統(tǒng)，每個用戶都相當(dāng)于一份備份， 管理員無需為數(shù)據(jù)備份而擔(dān)心。再有Git中包括提交、文件內(nèi)容等都通過SHA1哈希保證數(shù)據(jù)的完整性， 任何惡意篡改歷史數(shù)據(jù)都會被及時發(fā)現(xiàn)從而被挫敗。

更多的十條喜歡Git的理由

更多的十條喜歡Git的理由，參見 《Git權(quán)威指南》 第11-21頁。

● 異地協(xié)同工作

● 現(xiàn)場版本控制

● 重寫提交說明

● 無盡的后悔藥

● 更好用的提交列表

● 更好的差異比較

● 工作進(jìn)度保存

● 作為SVN前端實現(xiàn)移動辦公

● 無處不在的分頁器

● 快

什么情況推薦使用SVN

SVN具有的悲觀鎖的功能，能夠?qū)崿F(xiàn)一個用戶在編輯時對文件進(jìn)行鎖定，阻止多人同時編輯 一個文件。這一悲觀鎖的功能是 Git 所不具備的。對于以二進(jìn)制文件 （Word文檔、PPT演示稿） 為主的版本庫，為避免多人同時編輯造成合并上的困難， 建議使用SVN做版本控制。