Git'i Windows'ta (msysGit ile) bir süredir kullanıyorum ve dağıtılmış kaynak kontrolü fikrini seviyorum. Son zamanlarda Mercurial'a (hg) bakıyordum ve ilginç görünüyor. Ancak başımı hg ve git arasındaki farkların etrafına dolamıyorum.
Git ve hg arasında yan yana bir karşılaştırma yapan var mı? Bir fanboy tartışmasına girmek zorunda kalmadan hg ve git'in neyin farklı olduğunu bilmek istiyorum.
Yanıtlar:
Bu makaleler yardımcı olabilir:
Düzenleme : Git ve Mercurial'ı ünlülerle karşılaştırmak bir eğilim gibi görünüyor. İşte bir tane daha:
Mercurial üzerinde çalışıyorum, ancak temelde her iki sistemin de eşdeğer olduğuna inanıyorum. Her ikisi de aynı soyutlamalarla çalışır: tarihi oluşturan bir dizi anlık görüntü (değişiklik kümesi). Her değişiklik kümesi nereden geldiğini bilir (üst değişiklik kümesi) ve birçok alt değişiklik kümesine sahip olabilir. Yeni hg-git uzantısı Mercurial ve Git arasında iki yönlü bir köprü sağlar ve bu noktayı gösterir.
Git, bu tarih grafiğini mutasyona (odaklanan tüm sonuçlarla birlikte) güçlü bir şekilde odaklanırken, Mercurial tarihin yeniden yazılmasını teşvik etmez, ancak yine de bunu yapmak kolaydır ve bunu yapmanın sonuçları tam olarak olmasını beklemeniz gereken şeydir (yani , zaten sahip olduğunuz bir değişiklik kümesini değiştirirsem, müşteriniz benden alırsanız yeni olarak görür). Yani Mercurial'ın tahribatsız emirlere karşı bir önyargısı var .
Hafif dallara gelince, Mercurial o zamandan beri birden fazla şubeye sahip depoları destekledi ..., her zaman sanırım. Birden çok şubeye sahip Git depoları tam olarak şöyledir: Tek bir depoda çok farklı sapma geliştirme dizileri. Git daha sonra bu şeritlere adlar ekler ve bu adları uzaktan sorgulamanıza izin verir. Yer imleri Mercurial için uzatma yerel isimleri ekler ve itme / çekme zaman Mercurial 1.6 ile, etrafında bu imlerini taşıyabilirsiniz ..
Linux kullanıyorum, ancak görünüşe göre TortoiseHg, Windows'ta Git eşdeğerinden daha hızlı ve daha iyi (kötü Windows dosya sisteminin daha iyi kullanılması nedeniyle). Hem http://github.com hem de http://bitbucket.org çevrimiçi barındırma sağlar, Bitbucket'teki hizmet harika ve duyarlı (github'u denemedim).
Temiz ve zarif hissettirdiği için Mercurial'ı seçtim - Git ile aldığım kabuk / Perl / Ruby komut dosyaları tarafından ertelendi. Ne demek istediğimi bilmek istiyorsanız git-instaweb.shdosyaya bir göz atmayı deneyin : bir web sunucusu çalıştırdığını düşündüğüm Ruby komut dosyası oluşturan bir kabuk komut dosyasıdır. Kabuk betiği, ilk Ruby betiğini başlatmak için başka bir kabuk betiği oluşturur. İyi bir ölçü için biraz Perl de var .
Mercurial ve Git'i James Bond ve MacGyver ile karşılaştıran blog gönderisini beğendim - Mercurial, Git'ten bir şekilde daha düşük anahtar. Bana öyle geliyor ki, Mercurial kullanan insanlar o kadar kolay etkilenmiyorlar. Bu, her sistemin Linus'un "ŞİMDİ en havalı birleştirme!" . Git'te aşağıdakileri yaparak ilgisiz bir havuzla birleştirebilirsiniz:
git fetch <project-to-union-merge>
GIT_INDEX_FILE=.git/tmp-index git-read-tree FETCH_HEAD
GIT_INDEX_FILE=.git/tmp-index git-checkout-cache -a -u
git-update-cache --add -- (GIT_INDEX_FILE=.git/tmp-index git-ls-files)
cp .git/FETCH_HEAD .git/MERGE_HEAD
git commit
Bu komutlar gözüme oldukça gizemli görünüyor. Mercurial'ta şunları yaparız:
hg pull --force <project-to-union-merge>
hg merge
hg commit
Mercurial komutlarının nasıl sade ve hiç de özel olmadığına dikkat edin - olağandışı tek şey, gerekli olmayan --forcebayraktır hg pull, çünkü Mercurial ilgisiz bir depodan çektiğinizde aksi takdirde iptal olur. Mercurial'ı benim için daha zarif yapan bu gibi farklılıklar.
git pull <url-of-project>. alıntıladığınız posta git (2005) 'in ilk günlerinden
Git bir platform, Mercurial “sadece” bir uygulamadır. Git, kutuda bir DVCS uygulamasıyla birlikte gelen sürümlü bir dosya sistemi platformudur, ancak platform uygulamaları için normal olarak, daha karmaşıktır ve odaklanmış uygulamalardan daha pürüzlü kenarlara sahiptir. Ancak bu, git'in VCS'sinin son derece esnek olduğu ve git ile yapabileceğiniz çok büyük bir kaynak kontrolü olmayan şeyler derinliği olduğu anlamına gelir.
Farkın özü budur.
Git en iyi sıfırdan depo formatına kadar anlaşılır. Scott Chacon'dan Git Talk bunun için mükemmel bir başlangıç. Git'in kaputun altında neler olduğunu bilmeden kullanmaya çalışırsanız, bir noktada kafanız karışır (sadece çok temel işlevselliğe bağlı kalmazsanız). İstediğiniz tüm günlük programlama rutin bir DVCS olduğunda Aptalca gelebilir ama Git dehası depo biçimi aslında çok basit olduğunu ve sen yapabilirsiniz oldukça kolay seyahatseverlerin Git en bütün operasyonu anlıyoruz.
Daha fazla teknik odaklı karşılaştırma için, şahsen gördüğüm en iyi makaleler Dustin Sallings'in:
Aslında her iki DVCS'yi de yoğun olarak kullandı ve ikisini de iyi anladı - ve git'i tercih etti.
En büyük fark Windows'ta. Mercurial yerel olarak desteklenir, Git desteklemez. İçin çok benzer barındırma alabilirsiniz github.com ile bitbucket.org (bir ücretsiz özel depo olsun daha iyi bile aslında). Bir süredir msysGit kullanıyordum ama Mercurial'a taşındım ve bundan çok memnun oldum.
Bağlantısı kesilmiş temel düzeltme denetimini arayan bir Windows geliştiricisiyseniz, Hg. Hg basit ve Windows kabuğuyla iyi entegre edilmişken Git'in anlaşılmaz olduğunu gördüm. Hg'yi indirdim ve bu öğreticiyi takip ettim (hginit.com) - on dakika sonra yerel bir repo yaptım ve projemde çalışmaya geri döndüm.
Bence "Mercurial vs. Git" hakkında en iyi açıklama:
Neredeyse aynılar. Benim açımdan en önemli fark (yani, bir DVCS'yi diğerine seçmemin sebebi) iki programın şubeleri nasıl yönettiğidir.
Mercurial ile yeni bir şube başlatmak için, depoyu başka bir dizine kopyalayıp geliştirmeye başlamanız yeterlidir . Sonra çekip birleştiriyorsun. Git ile, kullanmak istediğiniz yeni konu dalına açıkça bir ad vermeniz gerekir, ardından aynı dizini kullanarak kodlamaya başlarsınız .
Kısacası, Mercurial'daki her şubenin kendi dizinine ihtiyacı vardır; git'te genellikle tek bir dizinde çalışırsınız. Mercurial'ta şubeleri değiştirmek, dizinleri değiştirmek anlamına gelir; git'te git'ten, dizinin içeriğini git checkout ile değiştirmesini istemek anlamına gelir.
Dürüstüm: Mercurial ile aynı şeyi yapmanın mümkün olup olmadığını bilmiyorum, ancak genellikle web projelerinde çalıştığımdan, git ile her zaman aynı dizini kullanmak benim için çok rahat görünüyor, çünkü -Apache'yi yapılandırın ve yeniden başlatın ve her şubemde dosya sistemimi bozmuyorum.
Düzenleme: As Deestan Hg etti kaydetti dalları adında tek bir depoda saklanan ve aynı çalışma kopyası içinde anahtar dallarına geliştiricinin edilebilir. git şubeleri Mercurial adlı şubelerle tam olarak aynı değildir, zaten: onlar kalıcıdır ve git'teki gibi dalları atmazlar. Bu, deneysel görevler için adlandırılmış bir dal kullanırsanız, onu asla birleştirmemeye karar verseniz bile, depoda depolanır. Bu nedenle Hg, serbest bırakma dalları gibi deneysel, kısa çalışan görevler için klonları ve uzun süren görevler için adlandırılmış dalları kullanmaya teşvik eder.
Birçok Hg kullanıcısının klonları tercih edilen şubeye tercih etmesinin nedeni teknikten çok daha sosyal veya kültürel. Örneğin, Hg'nin son sürümlerinde, adlandırılmış bir dalı kapatmak ve meta verileri değişiklik kümelerinden özyineli olarak kaldırmak bile mümkündür.
Diğer tarafta git, kalıcı olmayan ve her değişiklik kümesinde meta veri olarak depolanmayan "adlandırılmış dalları" kullanmaya davet eder.
Benim kişisel bakış açımdan, git'in modeli, adlandırılan dallar kavramıyla derinden bağlantılıdır ve aynı dizine sahip bir dal ile bir diğeri arasında geçiş yapar; hg aynı şeyi adlandırılmış dallarla da yapabilir, ancak yine de kişisel olarak çok sevmediğim klonların kullanımını teşvik ediyor.
Bir tane var kocaman arasındaki fark Git ve cıva ; her bir taahhüdü temsil etme şekli. git taahhütleri anlık görüntü olarak, mercurial ise farkları temsil eder.
Bu pratikte ne anlama geliyor? Git'te başka bir işleme geçme, taahhütleri karşılaştırma vb. Gibi birçok işlem daha hızlıdır. Özellikle bu taahhütler çok uzaktaysa.
AFAIK'ın mercurial'ın yaklaşımından hiçbir avantajı yoktur.
Hiçbir şey değil. İkisi de aynı şeyi yapıyor, ikisi de eşit performans gösteriyor. Birini diğerinden seçmeniz için tek neden, zaten birini kullanan bir projeye yardım etmenizdir.
Birini seçmenin diğer olası nedeni, sadece sistemden birini destekleyen bir uygulama veya hizmettir. Örneğin, github yüzünden gitmeyi öğrenmeyi seçtim .
Ayrıca google'ın karşılaştırması (biraz eski olsa da, 2008'de yapıldı)
Onları doğru anlarsam (ve her birinde uzman olmaktan uzaksam) temelde her birinin farklı bir felsefesi vardır. İlk önce 9 ay boyunca cıva kullandım. Şimdi git'i 6 için kullandım.
hg sürüm kontrol yazılımıdır. Temel amacı bir yazılımın sürümlerini takip etmektir.
git zamana dayalı bir dosya sistemidir. Amacı bir dosya sistemine başka bir boyut eklemektir. Çoğu dosya ve klasöre sahiptir, git zaman ekler. Bir VCS olarak harika çalışmanın tasarımının bir yan ürünü olması.
Hg'de, her zaman sürdürmeye çalıştığı tüm projenin bir geçmişi vardır. Varsayılan olarak hg'nin itme ve çekme sırasında tüm kullanıcılar tarafından tüm nesnelerde tüm değişiklikleri istediğine inanıyorum.
Git'te sadece bir nesne havuzu ve bu izleme dosyalarının (dallar / kafalar) belirli bir durumdaki dosya ağacını temsil ettiğini belirleyen bu izleme dosyaları (dallar / başlıklar) vardır. Git'i iterken veya çekerken, yalnızca ittiğiniz veya çektiğiniz belirli dallar için gereken nesneleri gönderir, bu da tüm nesnelerin küçük bir alt kümesidir.
Git söz konusu olduğunda "1 proje" yoktur. Aynı repoda 50 projeniz olabilir ve git umursamazdı. Her biri aynı repoda ayrı ayrı yönetilebilir ve iyi yaşayabilir.
Hg'nin şubeler kavramı ana projenin şubeleri veya şubeler vb. Git'teki bir dal sadece ağacın durumudur, her şey Git'teki bir daldır. Hangi dalın resmi, güncel veya en yeni olduğu, git'te hiçbir anlam ifade etmiyor.
Bunun bir anlam ifade edip etmediğini bilmiyorum. Eğer resim çizebilseydim, hg bu gibi görünebilir.o
o---o---o
/
o---o---o---o---o---o---o---o
\ /
o---o---o
Tek bir kök ve dallardan çıkan bir ağaç. Git bunu yapabilir ve çoğu zaman insanlar zorla kullanılmayan şekilde kullanır. Git resmi, eğer böyle bir şey varsa, kolayca böyle görünebilir
o---o---o---o---o
o---o---o---o
\
o---o
o---o---o---o
Aslında bazı yönlerden git'te şubeleri göstermek bile mantıklı değil.
Tartışma için çok kafa karıştırıcı olan bir şey, git ve mercurial'ın her ikisi de "dal" olarak adlandırılan bir şey var, ancak uzaktan aynı şey değiller. Farklı depolar arasında anlaşmazlıklar olduğunda, mercurial'daki bir dal ortaya çıkar. Git'teki bir dal görünüşe göre hg cinsinden bir klona benzer. Ancak bir klon, benzer davranışlar verebilirken kesinlikle aynı değildir. Bunları git vs hg'de oldukça büyük olan krom repo kullanarak denemeyi düşünün.
$ time git checkout -b some-new-branch
Switched to new branch 'some-new-branch'
real 0m1.759s
user 0m1.596s
sys 0m0.144s
Ve şimdi hg'de klon kullanarak
$ time hg clone project/ some-clone/
updating to branch default
29387 files updated, 0 files merged, 0 files removed, 0 files unresolved.
real 0m58.196s
user 0m19.901s
sys 0m8.957
Her ikisi de sıcak koşu. Yani, onları iki kez çalıştırdım ve bu ikinci koşu. hg klonu aslında git-new-workdir ile aynıdır. Bunların her ikisi de neredeyse yazmışsınız gibi tamamen yeni bir çalışma direktörücp -r project project-clone . Bu git'te yeni bir dal yapmakla aynı şey değil. Çok daha ağır. Git'in dallanmasının hg cinsinden gerçek eşdeğeri varsa bunun ne olduğunu bilmiyorum.
Bazı düzey hg de anlamak ve git olabilecek benzer şeyleri yapmaya muktedir. Eğer öyleyse, sizi yönlendirdikleri iş akışında hala büyük bir fark vardır. Git'te tipik iş akışı, her özellik için bir dal oluşturmaktır.
git checkout master
git checkout -b add-2nd-joypad-support
git checkout master
git checkout -b fix-game-save-bug
git checkout master
git checkout -b add-a-star-support
Bu, her biri master adı verilen bir dalı temel alan 3 şube oluşturdu. (Eminim git'te 2 yerine 1 satır yapmanın bir yolu vardır)
Şimdi sadece üzerinde çalıştığım
git checkout fix-game-save-bug
ve çalışmaya başlayın. İşleri yapın, vb. Krom kadar büyük bir projede bile şubeler arasında geçiş yapmak neredeyse anlıktır. Aslında bunu hg olarak nasıl yapacağımı bilmiyorum. Okuduğum öğreticilerin bir parçası değil.
Bir diğer büyük fark. Git'in sahnesi.
Git'in bir sahne fikri var. Bunu gizli bir klasör olarak düşünebilirsiniz. Taahhüt ettiğinizde, çalışma ağacınızdaki değişiklikleri değil, yalnızca sahnede olanları taahhüt edersiniz. Kulağa garip gelebilir. Çalışma ağacınızdaki tüm değişiklikleri yapmak istiyorsanız git commit -a, değiştirilen tüm dosyaları sahneye ekleyen ve sonra bunları taahhüt eden yapardınız .
Sahnenin amacı ne? Taahhütlerinizi kolayca ayırabilirsiniz. Joypad.cpp ve gamesave.cpp dosyalarını düzenlediğinizi ve bunları ayrı ayrı taahhüt etmek istediğinizi düşünün
git add joypad.cpp // copies to stage
git commit -m "added 2nd joypad support"
git add gamesave.cpp // copies to stage
git commit -m "fixed game save bug"
Git'in aynı dosyadaki hangi belirli satırların sahneye kopyalamak istediğinize karar verme komutları bile vardır, böylece bu taahhütleri ayrı olarak bölebilirsiniz. Bunu neden yapmak istiyorsun? Çünkü ayrı taahhütler olarak diğerleri sadece istediklerini çekebilirler ya da bir sorun varsa, sadece sorunu içeren taahhüdü geri alabilirler.
git add --patchbkz. Linux.die.net/man/1/git-add veya kullanım git add -i, stackoverflow.com/questions/2372583/…
checkout -b <name>sizinle dallanmak yerine, git branch <name>ona geçmeden yeni bir dal oluşturmak için kullanabilirsiniz
Versioncontrolblog'da birkaç farklı sürüm kontrol sistemini karşılaştırabileceğiniz dinamik bir karşılaştırma tablosu vardır.
dir-a/foo.ciçin dir-b/foo.cve üzerinde çalışmaya devam dir-b/foo.c, ardından iş dir-a/foo.colacak doğru bir çekme eyleminden sonra benim iş ile birleşti.
Şubelerle çalışmak söz konusu olduğunda (özellikle kısa vadeli olanlar) oldukça önemli farklılıklar vardır.
Mercurial'ı Git ile karşılaştıran bu makalede (Branching Explained) açıklanmıştır .
Projenizde Windows tabanlı ortak çalışan var mı?
Çünkü varsa, Windows için Git GUI garip, zor ve düşmanca görünüyor.
Windows üzerinde Mercurial, aksine, beyinsizdir.
Geçen yıl bazen git ve hg'yi kendi kullanımım için değerlendirdim ve hg ile gitmeye karar verdim. Daha temiz bir çözüm gibi geldiğini hissettim ve o zaman daha fazla platformda daha iyi çalıştı. Yine de çoğunlukla bir savurganlık oldu.
Daha yakın zamanda git-svn ve Subversion istemcisi gibi davranma yeteneği nedeniyle git kullanmaya başladım. Bu beni kazandı ve şimdi tamamen git'e geçtim. Bence biraz daha yüksek bir öğrenme eğrisi var (özellikle de içeride dolaşmanız gerekiyorsa), ama gerçekten harika bir sistem. John'un şimdi yayınladığı iki karşılaştırma makalesini okuyacağım.
Şu anda SVN'den DVCS'ye geçme sürecindeyim (bulgularım hakkında blog yazarken, ilk gerçek bloglama çabam ...) ve biraz araştırma yaptım (= googling). Görebildiğim kadarıyla her iki paketi de yapabilirsiniz. Git birkaç veya daha iyi uygulanan gelişmiş özelliklere sahip gibi görünüyor, Windows ile entegrasyonun TortoiseHg ile cıva için biraz daha iyi olduğunu hissediyorum. Git Cheetah'ın da olduğunu biliyorum (her ikisini de denedim), ancak cıva çözümü daha sağlam hissettiriyor.
İkisinin de açık kaynak kodlu olduklarını görünce (değil mi?) Ben de önemli özelliklerin olmadığını düşünüyorum. Bir şey önemliyse, insanlar bunu isteyecek, insanlar kodlayacaktır.
Ortak uygulamalar için Git ve Mercurial'ın fazlasıyla yeterli olduğunu düşünüyorum. Her ikisinin de onları kullanan büyük projeleri var (Git -> linux çekirdeği, Mercurial -> Mozilla vakıf projeleri, ikisi de tabii ki), bu yüzden ikisinin de gerçekten bir şeyleri olmadığını düşünüyorum.
Bununla birlikte, bloglama çabalarım için mükemmel bir kaynak olacağından, başkalarının bu konuda ne söylediğiyle ilgileniyorum ;-)
InfoQ'nun DVCS hakkındaki kılavuzunda git, Mercurial ve Bazaar'da harika ve kapsamlı bir karşılaştırma tabloları ve çizelgeleri var .
Bunun cevabın bir parçası olmadığını anlıyorum, ancak bu notta, NetBeans ve Eclipse gibi platformlar için kararlı eklentilerin kullanılabilirliğinin, aracın hangi görev için daha uygun olduğunu ya da hangi aracın "siz" için en uygunudur. Eğer gerçekten CLI yolu yapmak istemiyorsanız.
Hem Eclipse (ve buna dayalı her şey) hem de NetBeans bazen uzak dosya sistemleri (SSH gibi) ve dosyaların harici güncellemeleri ile ilgili sorunlara sahiptir; bu da "sorunsuz" çalışmayı seçmenizin bir başka nedeni.
Ben de şu anda bu soruyu kendim için cevaplamaya çalışıyorum .. Ve adayları Git ya da Mercurial'a kaynattım. Dinlenmeden bu konuda faydalı girdiler sağladığınız için hepinize teşekkür ederim.
Mercurial ve git'in bir başka ilginç karşılaştırması: Mercurial vs Git . Ana odak iç kısımlar ve bunların dallanma sürecine etkisi.
Mercurial ve Git'in performans karşılaştırmasıyla ilgileniyorsanız, bu makaleye göz atın . Sonuç:
Git ve Mercurial her ikisi de iyi rakamlara dönüşüyor, ancak hız ve veri havuzu boyutu arasında ilginç bir değiş tokuş yapıyor. Mercurial, hem ekleme hem de modifikasyonlarla hızlıdır ve aynı zamanda depo büyümesini kontrol altında tutar. Git de hızlıdır, ancak yeniden paketleninceye kadar deposu değiştirilmiş dosyalarla çok hızlı büyür ve bu yeniden paketlemeler çok yavaş olabilir. Ancak paketlenmiş depo Mercurial'ınkinden çok daha küçüktür.
Mercurial web sitesi, iki sistem arasındaki benzerlik ve farklılıkların, kelime dağarcığının ve temel kavramların farklılıklarını açıklayan harika bir açıklamasına sahiptir . Git kullanıcısı olarak, Mercurial zihniyetini anlamama yardımcı oldu.
SVN'den geçiş yapıyorsanız, sözdizimi SVN kullanıcıları için ÇOK daha anlaşılır olduğu için Mercurial'ı kullanın. Bunun dışında da yanlış gidemezsin. Ancak bunlardan birini seçmeden önce GIT eğitimini ve HGinit'i kontrol edin .
Bu bağlantı farkı anlamanıza yardımcı olabilir http://www.techtatva.com/2010/09/git-mercurial-and-bazaar-a-comparison/
Bazı insanlar VCS sistemlerinin karmaşık olması gerektiğini düşünüyor. Sahada terim ve kavramların icat edilmesini teşvik ederler. Muhtemelen bu konuda çok sayıda doktora yapmanın ilginç olacağını düşünürlerdi. Bunlar arasında muhtemelen Git'i tasarlayanlar da var.
Mercurial farklı bir zihniyetle tasarlanmıştır. Geliştiriciler VCS'yi fazla önemsememeli ve bunun yerine zamanlarını ana işlevlerine harcamalıdırlar: yazılım mühendisliği. Mercurial, kullanıcıların kurtarılamaz hatalar yapmasına izin vermeden sistemi kullanmasına ve mutlu bir şekilde kötüye kullanmasına olanak tanır.
Herhangi bir profesyonel araç, açıkça tasarlanmış ve sezgisel bir CLI ile gelmelidir. Mercurial kullanıcıları, garip seçenekler olmadan basit komutlar vererek işin çoğunu yapabilir. Git çift tire, çılgın seçenekler normdur. Eğer CLI'lı bir kişi iseniz (ve dürüst olmak gerekirse, kendine saygılı herhangi bir Yazılım Mühendisi olmalıdır) Mercurial'ın önemli bir avantajı vardır.
Bir örnek vermek gerekirse, yanlışlıkla bir taahhütte bulunduğunuzu varsayalım. Bazı dosyaları düzenlemeyi unuttunuz. Mercurial'taki eyleminizi geri almak için şunları yazmanız yeterlidir:
$ hg rollback
Daha sonra, sistemin son işleminizi geri aldığını belirten bir mesaj alırsınız.
Git'e şunu yazmalısınız:
$ git reset --soft HEAD^
Yani tamam sıfırlamanın ne hakkında olduğu hakkında bir fikriniz olduğunu varsayalım. Ancak ek olarak "--soft" ve "--hard" sıfırlamalarının ne olduğunu bilmek zorundasınız (sezgisel tahminler?). Oh ve elbette sonunda '^' karakterini unutmayın! (şimdi Ritchie'nin adının ne olduğu ...)
Mercurial'ın kdiff3 ve meld gibi 3. taraf araçlarla entegrasyonu da çok daha iyi. Yamalarınızı oluşturun dalları fazla karışıklık olmadan birleştirin. Mercurial ayrıca, yazarak etkinleştirdiğiniz basit bir http sunucusu içerir
hg serve
Ve diğerlerinin deponuza göz atmasına izin verin.
Sonuç olarak Git, Mercurial'ın yaptıklarını çok daha karmaşık bir şekilde ve çok daha düşük bir CLI ile yapıyor. Projenizin VCS'sini bilimsel araştırma alanına dönüştürmek istiyorsanız Git'i kullanın. VCS işini fazla önemsemeden yapmak istiyorsanız Mercurial'ı kullanın ve gerçek görevlerinize odaklanın.