說到版本控制工具很多人可能都會馬上想到 CVS 和 Subversion，但自從開始使用 git 以後，我在自己的開發過程中都會優先選擇 git 而非前者。
最早從今年初就已經開始用 git。剛開始的時候會的確會感到 git 比較複雜，一個原因是它不同於 Subversion 這樣的集中式版本控制系統，在 Subversion 中只有一個倉庫（repository)，許多個工作目錄（working copy），而像 git 這樣的分部式版本控制系統中，每一個工作目錄都包含一個完整倉庫，倉庫之間內容可能不相同，可以進行倉庫之間的同步。另一個原因是 git 的命令非常之多，而它本身的概念也比較複雜（雖然 Linus 說git 是 stupid contenc tracker，但其實這個東西不適合傻瓜使用），還分 repository, index, working tree 等，直接使用也會比較麻煩些，所以我實際一直都是使用 cogito，只有必要的時候才直接使用 git。
爲什麼要使用分佈式的版本控制系統？Subversion 有什麼不好？
我最開始使用 Subversion 時一直覺得有一點很不爽，如果我想把某個已有的項目使用Subversion 來進行管理，首先要建立一個倉庫，然後把文件 import 到倉庫，最後再check out，然後在 check out 的工作目錄中再進行修改。爲什麼要那麼麻煩？我只是自己一個人進行開發而已，爲什麼非要有一個倉庫？此其一，只是不爽而已。
第二點使我沒有辦法使用 Subversion，不得不尋找其他的工具。我要在幾臺電腦上同時進行開發，我希望在每一臺電腦上都能使用版本控制工具。所以我需要有一個放在優盤上的倉庫，這個時候使用 Subversion 就有問題了。一來當你提交時你必須得把優盤插上電腦，每次提交都得插上；二來倉庫在優盤上的位置不能改變，否則路徑改變的話使用 file 協議拷貝出來的工作目錄就廢了。（我查過 svn propset 的幫助，似乎可以改變倉庫地址，但我不會，網上也沒有搜到。）
這兩個問題 git 都可以很好的解決（嚴格來說我使用的是 cogito）。要把已有的文件加入版本控制的話使用 cg init 一條命令即可。而分佈式的版本控制系統解決第二個問題實在是再適合不過了。在優盤上建立一個倉庫，不同機器上的倉庫在開發時就儘管 commit 到本地的倉庫好了，在要換機器之前先把修改 push 到優盤上的倉庫，到其他機器上時 pull 出來然和 merge 一下就好了，cogito 可以直接使用 update 完成這兩步操作。而優盤上倉庫路徑如果有改變的話可以使用 cg-branch-chg 很方便的修改遠程倉庫的地址。實際可以認爲優盤上的倉庫就是一箇中央倉庫，所以有許多個倉庫其實並不是一件可怕的事情，也完全可以像使用集中式的版本控制系統那樣自定一個爲中央倉庫即可。但分佈式的版本控制系統不強制你這麼做，給你更多的靈活性。
更加讓我喜歡 git 的是它的 branch 概念。我在使用 Subversion 的時候從來沒有用過，因爲它的 branch 概念是通過 copy 來實現的（當然不是實際的拷貝），不夠直觀。目前我只用 branch 來進行實驗性的開發。而 Linus使用 git 管理內核開發時通過 branch 來整合多人所做的修改，內核有那麼多的 branch，Linus 通過 git 可以很輕鬆的 merge 這些不同的 branch 所做的修改，最後從他自己的倉庫中發佈新版本的 Linux 內核。
此外 git 對磁盤空間的利用也更高效（不過需要定期對倉庫使用 git repack -d 命令以後），其他方面性能也都很出色。想想它要管理 Linux 內核那麼大的項目就可以知道了。
Linus 在 Google Tech talk 上做過 git 的介紹，以及他是如何使用 git 來管理內核開發的。他的演講裏面對分佈式版本控制系統的好處有更好的說明。不過 Linus 自己也承認自己是個 strong opinion person，它在演講的時候多次說集中式的版本控制系統沒有前途，因此 Subversion 的開發者想要開發一個更好的 CVS 其實是腦子出了毛病，實在是太 offensive 了，好在他是 Linus，大家都知道他的個性。（他還說過自己是 digust pig, and proud of it，汗啊……）
但是，但是……
git 很好，可是它不跨平臺，至少在非 Linux 平臺上運行的沒有那麼好，在非 Linux 文件系統上會有麻煩。我雖然不在 Windows 上做開發，但是最近要在 Solaris 上做開發，我不想花時間在 Solaris 上把 git 裝起來，而且如果以後如果要和其他使用 Windows 的人合作的話我可不想再使用 Subversion。所以我需要一個替代 git 的工具。這篇文章介紹了 Mozilla“移向”新版本控制工具時是如何做出選擇。（原文強調是 “move” 而不是 “pick”，因爲最後的候選者都很好。）首先肯定要用分佈式的，然後在 4 個分佈式的版本控制工具中篩選，git 和 Monotone 因爲支持平臺問題而被排除，剩下 Bazaar 和 Mercurial。前者有 Canonicol 在支持。而後者已經是 OpenSolaris 等著名項目的版本控制工具，而且有着非常好的文檔，可以很方便的使用 python 的 web server 發佈項目。在 Mozilla 的版本控制工具選擇中 Mercurial 最終因爲性能而勝出。所以我也決定轉到 Mercurial 去了，看了看文檔，感覺和 cogito 很像，比 git 更簡單，遷移過程應該會比較順利。
另外提一下，分佈式的版本控制工具還有 darcs, arch。前者是用 Haskell 寫的，後者據說很複雜。而 git 則是受到 Monotone 的影響。
原文網址：
http://my.donews.com/chenyufei/2007/06/24/post-070624-094733-899/