最近有項(xiàng)目需要多人在異地協(xié)同開(kāi)發(fā),用什么來(lái)做配置管理呢?
          當(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 下圖片:

          Start HG Web Server

          啟動(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早:)
          Git GUI
          相對(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)便易用的。




          Feedback

          # re: Git Vs Mercurial hg? 異地協(xié)同開(kāi)發(fā),分布式SCM方案選擇!  回復(fù)  更多評(píng)論   

          2009-04-29 05:35 by yuz estetigi
          thank you very good site...

          # re: Git Vs Mercurial hg? 異地協(xié)同開(kāi)發(fā),分布式SCM方案選擇!  回復(fù)  更多評(píng)論   

          2009-04-29 05:36 by yuz estetigi
          thank you very good site

          # re: Git Vs Mercurial hg? 異地協(xié)同開(kāi)發(fā),分布式SCM方案選擇!  回復(fù)  更多評(píng)論   

          2009-05-06 07:31 by bwlee
          有個(gè)朋友看了我的這篇筆記后,給我提了點(diǎn)意見(jiàn),在這兒回復(fù)一下,順便作點(diǎn)簡(jiǎn)單的說(shuō)明:

          他的第一個(gè)意見(jiàn)是,這東西寫(xiě)得不太清楚,比如HG跟Mercurial是什么關(guān)系沒(méi)說(shuō)清楚,我想,這個(gè)問(wèn)題應(yīng)該這樣來(lái)看,博客是自我的筆記,大家可以互相參考下,能帶來(lái)點(diǎn)思路的啟發(fā),但不是教科書(shū),官網(wǎng)上這類(lèi)東西很多。再說(shuō)了,寫(xiě)博客也沒(méi)稿費(fèi)的,呵呵

          第二個(gè)意思是方案的選擇理由,以及相關(guān)的異地開(kāi)發(fā)并不只是要解決這一個(gè)軟件配置管理就夠了,這個(gè)倒是有點(diǎn)道理,的確,軟件配置管理只是一個(gè)基本的問(wèn)題,還有需求管理,開(kāi)發(fā)、團(tuán)隊(duì)間的交流討論,成員工作量的考核等,都是影響項(xiàng)目成敗的重要問(wèn)題。 但這一展開(kāi)就太大了,沒(méi)準(zhǔn)備寫(xiě)成一本書(shū):-)。
          不過(guò)既然提到了這些,順便把我的想法和做法大概列一下,歡迎批評(píng)指正。

          需求管理的工具很多,但工具之間必須配合好,才容易起到1+1>2的效果,所謂管理出效益,也是這個(gè)道理,簡(jiǎn)單的把人頭堆積起來(lái)更是不能直接加速項(xiàng)目進(jìn)程的,甚至可能起反效果。 比如ClearRequest和ClearCase之間就是個(gè)比較好的配合,但關(guān)鍵點(diǎn)是太貴了,這家伙是在大公司呆慣了,資源無(wú)限,從來(lái)不知道體諒下我等窮人的難處,呵呵。不過(guò)開(kāi)源免費(fèi)的東西也有,像Trac這個(gè)就是跟SVN結(jié)合得比較好的工具。但最終還是要有個(gè)中心的配置服務(wù)器才方便使用,我這個(gè)輕量級(jí)的方案(其實(shí)是超輕量級(jí)的,呵呵),要用這個(gè)的話(huà),也得搞個(gè)服務(wù)器,弄上Apache+SVN+Trac,或者是用比較流行的Bugzilla,但我對(duì)這些都有點(diǎn)不太感冒,說(shuō)實(shí)話(huà),在我的理解中,這些對(duì)故障跟蹤的系統(tǒng)用在需求管理上,總還是有點(diǎn)不自在,后期維護(hù)用才差不多。
          我更傾向于功能點(diǎn)的劃分,在提交時(shí)就是根據(jù)功能點(diǎn)來(lái)做,每個(gè)功能點(diǎn)提交一個(gè)變更集,其他的東西,可以在DVCS內(nèi)部作分支來(lái)解決,也就是在每個(gè)人的master分支上作團(tuán)隊(duì)同步,個(gè)人工作如果習(xí)慣上需要頻繁修改提交,可以在分支上進(jìn)行,先自行合并到master上,然后再同步。
          這個(gè)只允許按功能點(diǎn)提交變更的方法以前在用CVS時(shí)試過(guò),效果還不錯(cuò),強(qiáng)調(diào)寫(xiě)好每次的注釋?zhuān)瑖?yán)格按功能點(diǎn)來(lái)做,這樣,我在后期用statCVS統(tǒng)計(jì)的時(shí)候,也能比較清晰地弄明白各成員的工作量,方便項(xiàng)目總結(jié)時(shí)提供相關(guān)圖表給大家,而不是簡(jiǎn)單憑印象來(lái)評(píng)價(jià)團(tuán)隊(duì)的工作,造成團(tuán)隊(duì)部分成員的情緒問(wèn)題。Mercurial HG和Git目前都沒(méi)有這類(lèi)的工具,是個(gè)缺憾,但應(yīng)該很快就會(huì)有的,這兩類(lèi)工具的變更集和日志更完善,也支持外部插件,做個(gè)統(tǒng)計(jì)分析的工具成插件都可以。
          至于團(tuán)隊(duì)間的交流也好辦,大家約好時(shí)間,定下會(huì)議議程,開(kāi)個(gè)網(wǎng)絡(luò)視頻會(huì)議就搞掂了,至于工具,NetMeeting, MSN,還有skype什么的一大堆,關(guān)鍵是如何用好,我傾向于會(huì)議主要討論計(jì)劃及通報(bào)進(jìn)展,影響全體的技術(shù)問(wèn)題在會(huì)上討論下,否則,技術(shù)問(wèn)題還是在成員間自由交流比較合適,至于,技術(shù)的共享和培訓(xùn),在前期做下相關(guān)技術(shù)的培訓(xùn),后期團(tuán)隊(duì)成員的項(xiàng)目總結(jié)上作正式的交流比較好,項(xiàng)目進(jìn)行過(guò)程中還是不搞形式上太正式的技術(shù)研討,因?yàn)槿菀琢饔谛问剑膊粫?huì)有太深入的理解,除非是里程碑點(diǎn)出現(xiàn)了嚴(yán)重的偏差需要糾正,否則還是私下交流點(diǎn)實(shí)用的經(jīng)驗(yàn)更合適。

          # re: Git Vs Mercurial hg? 異地協(xié)同開(kāi)發(fā),分布式SCM方案選擇!  回復(fù)  更多評(píng)論   

          2009-11-24 19:10 by saç ekimi
          very useful informations thanks for sharing.They are too neccessary for me. I bookmarked.

          posts - 44, comments - 43, trackbacks - 0, articles - 5

          Copyright © 小李飛刀

          涉足江湖,廣交朋友
          尋找有共同興趣愛(ài)好者一起開(kāi)創(chuàng)掌上移動(dòng)應(yīng)用!


          歡迎光臨!您是第 hit counter 位訪客。
          主站蜘蛛池模板: 山东省| 中超| 榆林市| 青河县| 贵阳市| 牙克石市| 崇仁县| 白城市| 密山市| 天气| 保山市| 越西县| 卫辉市| 五大连池市| 吴忠市| 贺兰县| 嘉祥县| 襄樊市| 中阳县| 稻城县| 侯马市| 平昌县| 上虞市| 合山市| 丹东市| 固始县| 红桥区| 德兴市| 寿阳县| 嘉义市| 沾益县| 桐乡市| 神农架林区| 南投市| 霍林郭勒市| 崇阳县| 龙泉市| 新化县| 怀宁县| 郑州市| 高清|