個人對Mercurial和Git的不同感想

在熟悉了Git後，又找了點時間學了Mercurial。之前準備要學習Git時，就找了很多資料。Mercurial和Git的各種比較當然更是不能少，所以對Mercurial也很有興趣。

Mercurial和Git實際儲存的方式很類似，所以熟悉了Git再看來Mercurial覺得很多觀念都很容易理解。不過有趣的是，因為Mercurial和Git使用了類似的資料儲存，我們可以說Mercurial和Git是用不同的觀點來操作同一份資料，因些產了大異其趣的兩種VCS(這裡說大異其趣也是有點誇大，因為對使用觀念還是很相近)。網路上Google這個Git和Mercurial分析(中文版)雖然有點舊，但還是很不錯。

就我的觀點來說，其實Mercurial其實比較算是VCS。Git連History可以改的功能讓我不太能接受，但是rebase又實在很實用。在我熟悉了Git之後，覺得Git其實比較像是Revision Exchange System，很多的功能都是為了讓contributer能夠很方便的把update送給maintainer，而maintainer也能最方便的把contributer的update merge進maintainer的source。也為了如此Git幾乎把把有的能力都開放給user，但也就是開放的太多太強大，也很容易讓user把repository搞壞。Pro Git裡也強調己經publish的commit最好不好再change或刪除，包含有些功能的本質就是rewrite commit。

其實單就功能性和理念上來說，我是比較喜歡Mercurial的一些特點，包括commit history不能改變，比較平緩的學習曲線，使用跨平台的Python，user容易寫自己的extension，還有對http的高度整合。

但是以我現在的使用環境，最需要的是local branch、history rewrite、rebase。所以我現在使用Git。還有另一個理由是我沒有root的權限，只要把Git build在家目錄裡就可以，相對來說較方便。

Git讓我覺得最不方便的就是在架設server的部分，Mercurial在server部分功能也相對比較方便。也剛我現在只是個人使用，沒使用到server的部分，但是在可預的未來還是需要的。

其實以Mercurial和Git底層的高度相似度，應該不太有因為架構上的差異而有一種能提供而另一種無法做到的功能。我想多半是因為理念的不同而不提供(或是認為不應該提供)。能互相參考，把好用的功能互相補強，當然是最好不過。最好是還可而互通，像對svn一樣的支援就最好不過了。不過我想這應該是我想太多了。:)

之前看到Git支援svn，本來以為可以靠git svn完整支援，把git當svn client，現在發現實際使用上除了有點地方要小心以外，好像dcommit也還有一點不穩定。這樣讓使用起Git，也無法發揮Git的強大。

Mercurial目前對svn的支援度我還不清楚，不過我想我可以以Python當標杆，Python在等hgsubversion的完成度也要轉換到Mercurial。當Python轉到Mercurial後就意味著hbsubversion就到達一定的可用度了。

PS:Mercurial的default package也包括了一些很重要但預設是不開啟的extension，像rebase及能達到local branch的bookmark。這讓我更喜歡這種extension的設計，讓你在嚴謹管理中，也能有一些做例外的能力。而Git也正在討論對http的支援。大家都朝正面的道路前進。

--update 2011/0905
Git在1.7之後就支援smart http讓使用http push或pull時更有效率

Git的local branch果然好用

前一陣子將Pro Git讀完了，開始使用Git來輔助在公司的工作。Git的local branch真是好用。在公司使用公司的VCS，要達到一定的完整性和正確性後才能check in，在還沒check in前自己做不同測試也很不方便，老是要把檔案搬來搬去備份來備去，還要自己做merge。當要同時處理不同功能時就更辛苦了。改用Git後，這些事都方便很多。只是Git實在是也不算好學。網路上有許多的文章，很多人簡介，但是我覺那些對初學者來說其實還是不太夠。雖然最重要的部分都不會少，但是對初學者來說反而更霧裡看花。我一開始看也是先看別人的介紹，但是總覺無法擋掌握Git。最後還是看完了Pro Git之後才覺得真正知道如何使用。

所以現在就變成從公司的VCS check out到自己的local後再使用Git，在不同的local branch做不同的測試，甚至是同時做不同的功能。最後再最後的結果check in進公司。有點像git svn的做法，但是是手動版本。而且公司也不是用svn，git svn幫不上忙就是了。

而且有了Git的rebase和輕鬆merge能力，同時開的local branch最後很也容易就能和公司的VCS的最新版本接軌。除了有時會忘記現在build出來的binary到底是那個branch以外都很方便，我想就大概是太方便的後果吧。

git初步心得

最近了點時間一邊讀doc一邊操作終於比較了解git一點了。git這種分散式的版本控制系統果然是為社群開發方式的研發出來了。使用方式和邏輯很適合社群的開發模式。不過還真的不怎麼容易學。我自信對傳統集中式的版本控制己相當了解，也使用好多年，但還讀git的manual時還是常有一頭霧水的感覺。也許和我一直想用subversion而增加自己的困擾有關吧。

比較了解git一點後，覺得git比較像是版本的管理而不是版本的控制。當然這也是git對分散式版本控制系統的看法，應該是"檔案工具"而不是"控制工具"。所以要你手動作pack object、連提交過的版本都可以從歷史記錄裡抹除。-_-|||。這在社群使用上沒問題，但是公司團隊裡可能就會不一定合適了。當然這對git來說並不是無解。可以另外由一個管理者保有一份類似"權威版"的的方式來模擬像subversion這種集中式的管理方式。

不過git鼓勵多使用branch和merge的方式倒是滿好用的。當local branch不會影響任何人時，開發者更能盡情的做各種實驗，這當然也是受社群開發方式的影響，這種開發心態在一般的公司團隊裡也很有幫助。

就目前的試用心得來說覺得git有兩個部分還是不太習慣。

第一是使用hash當版本號碼讓版本號碼非常長，大部分的狀況下我都不看版本號碼而看commit log。也因為這樣的版本號碼不容易一眼就看出版本之間的前後關係。在一個開發速定穩定的團隊裡我甚至可以從號碼的差距猜出大約的時間差距。有時間一眼就看出前後關係還是很方便的。

另一個問題是和bug tracing system或ticket system的配合。因為大部分的bug tracing system都還是集中式的要和分散式的version control合作還是有些問題。我還沒試過，我想可能會有一些solution。但應該都還不完美。至少我看到我最愛的mantis好像有一些git的hooking，試過之後再說。