Git Vs Mercurial hg? 異地協(xié)同開(kāi)發(fā),分布式SCM方案選擇!
Posted on 2009-04-28 22:51 小李飛刀 閱讀(4042) 評(píng)論(4) 編輯 收藏 所屬分類(lèi): 開(kāi)發(fā)工具 、項(xiàng)目管理當(dāng)然,分布式的版本控制系統(tǒng)是首選,目前比較流行的有兩個(gè),Git和Mercurial(hg),為了比較決策,在網(wǎng)上搜了下,在Windows下開(kāi)發(fā)的話(huà),覺(jué)得hg更方便點(diǎn),尤其是有tortoiseHG,異地共享更簡(jiǎn)單,當(dāng)然,是指針對(duì)人數(shù)不多的團(tuán)隊(duì),不是太大的項(xiàng)目,沒(méi)有考慮性能問(wèn)題。否則,可能還是Git有優(yōu)勢(shì),想想看Linus的作品,目前用來(lái)管理Linux Kernel的開(kāi)發(fā),自然就明白了。
當(dāng)然,mercurial也不是不行,python的開(kāi)發(fā)就是用mercurial在管理,具體誰(shuí)更好就不討論了,關(guān)鍵是對(duì)我而言,哪個(gè)更加好用,簡(jiǎn)便才是硬道理!
覺(jué)得最方便的就是在于TortoiseHG集成了WEB Server,這樣,在同步的時(shí)候,只要簡(jiǎn)單地從右鍵菜單上啟動(dòng)web Server,就可以把repository 發(fā)布出來(lái),的確夠方便吧?
show 下圖片:
啟動(dòng)后是這樣的:
當(dāng)然,在啟動(dòng)前,你還可以把相關(guān)的參數(shù)配置一下,仔細(xì)研究下,里面的東西不少。
ps: 今天打開(kāi)看了下,閱讀量一夜之間就有了不少,謝謝大家的關(guān)注,想想應(yīng)該補(bǔ)充下內(nèi)容,以對(duì)得起大家的時(shí)間。
如果,你的機(jī)器在防火墻后,或者是沒(méi)有公共的域名,使用WEB Serve的方式就有些不方便。當(dāng)然,有不少的免費(fèi)域名可以通過(guò)3322.org或者花生殼申請(qǐng)賬號(hào),并通過(guò)客戶(hù)端使用。配置工作稍微麻煩點(diǎn),這里就不寫(xiě)了,有興趣的朋友可以參考下其他網(wǎng)上的說(shuō)明。
在這里要補(bǔ)充的是一個(gè)利用郵件來(lái)共享repository的途徑。
還是看圖說(shuō)話(huà),寫(xiě)個(gè)簡(jiǎn)要的梗概,具體的細(xì)節(jié)部分需要大家親自試一下才能體會(huì)得到。
1. 配置好郵箱設(shè)置
2. 發(fā)送變更
注:郵件中也可以發(fā)送patch,只是用文件附在郵件內(nèi)容中,需要手工再處理下,不推薦。
如果只是在交流溝通時(shí)用倒也方便,僅是看看,不實(shí)際合并時(shí)比較好。
3. 協(xié)作者從郵件附件中獲得:
相對(duì)而言,Git在windows上的GUI就簡(jiǎn)陋了些,尤其是沒(méi)有簡(jiǎn)便的web發(fā)布功能令它遜色好多---對(duì)我這個(gè)實(shí)用的懶人而言,呵呵。盡管我用Git比HG早:)
相對(duì)于這個(gè)GUI界面而言,個(gè)人覺(jué)得bash的命令行界面還更靈活些,在Linux平臺(tái)下,一些插件也使工作更加輕松和有效率。
附圖是MinGW下的Git Bash使用界面,包含有命令自動(dòng)完成,幫助使用等,也還算比較方便。
附: 這是另外一個(gè)人的意見(jiàn),英文的,就不翻譯了。
當(dāng)然,他也有他的道理----兼聽(tīng)則明,自己根據(jù)實(shí)際需要選擇合適的才是最重要的,畢竟,有助于輕松完成項(xiàng)目才是最重要的。
Git vs Mercurial - Why I chose git
Background and Our Needs
I first heard about distributed version control systems from Allan Odgaard on the TextMate blog. We’ve been working for about a year on Unison, which is a web application to develop online training. Our development has been so fast-paced at times we’ve been forced to push out releases more quickly than we could test them thoroughly. More than once we’ve needed to push out a less-than-stable feature for a high-profile client. We would later realize something wrong with the feature, but there was no way to go back.Branching and reverting changes in version control software is supposed to allow you to do these things, but both are so annoying in SVN that we never actually used either. We only kept a branch around when we wanted to make a release and continue development in the trunk. We would never have dared roll back any commits
Enter Distributed Version Control
Distributed Version Control promised to solve these problems for us. We would be able to branch as often as we liked, which would then allow us to keep branches around for longer without worrying about merging them later.
I first looked at git, then tried mercurial (hg) for awhile, then finally decided on git. I’m going to try to provide an unbiased review of some of their strengths and weaknesses.
Realize that both tools are good at merging, both have strong user communities, and they are very similar choices. I found good comparisons hard to come by.
Mercurial
Mercurial has several advantages over git.
Excellent Documentation: The hgbook helped me to understand the concepts
Cleaner Commands: The interface requires fewer options and flags
Intuitive Commands: The names they picked for reverting changes make more sense
Windows Support: They have a full windows client, although using it to make lots of branches would get crazy fast
It also has some disadvantages
“Named
Branches” suck: They added this feature as an afterthought. The way
everyone branches is by “cloning” a repository. So, if you want to work
in a new branch, you have to make a brand new copy of everything. The
implementation of named branches simply isn’t workable
Rewriting History is difficult: hg doesn’t have the features git does here
Git
Git has its own strengths
Branching is Supreme: This is a big
one. Git lets you make new branches at any time, and lets you switch
back and forth between them in one working copy.
Remote Branches:
Git can send and receive changes from several different public
repositories. This is useful if you need to publish more than one
branch so others can download your changes.
Merging and Rewriting
History: You can squash several commits together into one big commit
when you merge, getting rid of the useless messages. You can easily
pull a new version of the code you’re working on into your experimental
branches.
Disadvantages
Slightly more confusing: There are more commands by default, and the reverting commands are hard to keep straight at first
The Wrapup
The interface to Mercurial is easier, and I like their mainstream approach, but git is simply far better with anything advanced. I don’t feel that Mercurial can handle making branches for each feature you are developing, and doesn’t do a good job of pushing/pulling changes from public repositories.
In the end, we picked Git. I’m going to revisit mercurial in another year and see if they’ve finished adding a few more necessary features. I wanted a DVCS in the first place so I could branch like crazy, and Mercurial really doesn’t support it well enough.
Posted in Environs.
其實(shí),從DVCS本身來(lái)講,我也傾向于Git,它的功能更加完善,可能有些命令不是那么直接,不太容易理解,也比較多。但考慮到一個(gè)眾多志愿者參與的項(xiàng)目,像Linux Kernel這樣的集市式的開(kāi)發(fā)項(xiàng)目,Git作為一個(gè)目前來(lái)講近乎理想的方案的確為L(zhǎng)inux的快速發(fā)展起到了很大的作用,并且,它是Linus在長(zhǎng)期的BitKeeper使用經(jīng)驗(yàn)的基礎(chǔ)上開(kāi)發(fā)的,無(wú)論從需求把握的角度,還是從它的性能方面的設(shè)計(jì)考慮都有很多過(guò)人之處。
就我本人的經(jīng)驗(yàn)而言,從開(kāi)始做軟件開(kāi)發(fā)到現(xiàn)在,也有將近10個(gè)年頭了,經(jīng)歷過(guò)幾個(gè)公司,也參與過(guò)不少的大的項(xiàng)目,使用過(guò)幾種商業(yè)的、或是開(kāi)源的VCS,不少是被動(dòng)接受的,后來(lái)自己選擇,決策用什么,算是有些經(jīng)驗(yàn),但總體來(lái)講,這些VCS是各有千秋,適用才是最好的。
從接觸的先后順序來(lái)說(shuō),依次使用過(guò)VSS、CVS、ClearCase、Perforce、SVN、Git,前段時(shí)間才聽(tīng)說(shuō)HG,覺(jué)得不錯(cuò),現(xiàn)在為了新的項(xiàng)目,臨時(shí)學(xué)了下,總體來(lái)講,一般在局域網(wǎng)環(huán)境中使用的話(huà),我還是喜歡CVS,畢竟,這是個(gè)大家都熟悉的工具,簡(jiǎn)單易用,也不必再為了這個(gè)工具來(lái)專(zhuān)門(mén)花時(shí)間來(lái)培訓(xùn)團(tuán)隊(duì)人員,否則在使用過(guò)程造成的麻煩可能會(huì)帶來(lái)些不必要的開(kāi)銷(xiāo)。 但在異地開(kāi)發(fā)、或者是項(xiàng)目比較大,各部分難以齊頭并進(jìn)的時(shí)候,DVCS系統(tǒng)才是更好的選擇,另外一種應(yīng)該選用DVCS的情況是,當(dāng)項(xiàng)目需要嚴(yán)格的對(duì)外發(fā)布版本控制時(shí),選擇DVCS可以讓各小組內(nèi)部先保證小范圍的集成順利進(jìn)行,這樣可以避免在用集中式版本控制系統(tǒng)時(shí),在deadline前,出現(xiàn)大家同時(shí)提交,沖突不斷,拼命加班的情形。
如果,團(tuán)隊(duì)成員學(xué)習(xí)能力都比較強(qiáng),建議在局域網(wǎng)內(nèi)開(kāi)發(fā)時(shí),也選擇用Git這樣的DVCS,畢竟,個(gè)人習(xí)慣不一樣,每個(gè)人的開(kāi)發(fā)速度也不同,Git強(qiáng)大的分支管理和歷史記錄回溯功能,可以為項(xiàng)目進(jìn)展提供強(qiáng)大的靈活性,也肯定會(huì)提高整體的開(kāi)發(fā)效率。
相信,以后的版本管理中,類(lèi)似Git的工具將會(huì)成為主流,Git也會(huì)變得更加簡(jiǎn)便易用的。