Karşılaştırmalara bakıldığında, bana kendi özellik setleri arasında 1: 1 eşleme olabileceği anlaşılıyor. Ancak, sıkça zikredilen bir ifade "Mercurial daha kolaydır" dır. Bu ifadenin temeli nedir? (varsa)
Karşılaştırmalara bakıldığında, bana kendi özellik setleri arasında 1: 1 eşleme olabileceği anlaşılıyor. Ancak, sıkça zikredilen bir ifade "Mercurial daha kolaydır" dır. Bu ifadenin temeli nedir? (varsa)
Yanıtlar:
Örnek olay: Haydi, önceki tüm taahhütlerinizde kullanıcı adını değiştirmek istediğinizi söyleyelim. Çeşitli sebeplerden dolayı bunu birkaç kez yapmam gerekiyordu.
Git Sürümü
git filter-branch --commit-filter '
if [ "$GIT_COMMITTER_NAME" = "<Old Name>" ];
then
GIT_COMMITTER_NAME="<New Name>";
GIT_AUTHOR_NAME="<New Name>";
GIT_COMMITTER_EMAIL="<New Email>";
GIT_AUTHOR_EMAIL="<New Email>";
git commit-tree "$@";
else
git commit-tree "$@";
fi' HEAD
Mercurial Sürümü:
authors.convert.list dosyası:
<oldname>=<newname>
Komut satırı:
hg convert --authors authors.convert.list SOURCE DEST
Şimdi, hangisinin kullanımı daha kolay görünüyor?
Not: 2 yıl boyunca sadece Git'le çalışarak geçirdim, bu yüzden "Bundan nefret ediyorum, 2 saniyede alamadım" rantı.
Benim için kullanılabilirlik. Git, bir şeyler yapmanın bir linux yolu ile çok linux odaklı. Bu komut satırı, man sayfaları ve kendiniz bulmak anlamına gelir. Çok zayıf bir GUI'ye sahipti (not: bunu bir yıl öncesinden beri msysGit'e dayandırıyorum), bu sadece yoluma giriyor gibiydi. Ben zar zor kullanabilirdim
Komut satırı daha kötüydü. Linux odaklı bir program olarak, Windows'ta kullanımı çok zordu. Yerel bir liman yerine, gitmeyi çok daha zor hale getiren MinGW (Think cygwin) ile basit bir şekilde tamamladılar. MinGW, Windows Komut İstemi değildir ve sadece farklı davranır. Git’le çalışmanın tek yolu bu. Linux'ta bile düz komut satırıyla çalışmak tek yol gibi görünüyordu. RabbitVCS gibi projeler bazılarına yardımcı oldu ama çok güçlü değildi.
Komut satırı yönelimli yaklaşım ve linux program olmak, rehberlik, yardım dokümantasyonu ve forum / QA sorularının hemen hemen hepsinin yukarıdaki gibi korkunç komutları çalıştırmaya dayanması anlamına geliyordu. Temel SCM komutları (taahhüt etme, çekme, itme) karmaşık değildir, ancak daha fazla ve karmaşıklık katlanarak büyür.
Ayrıca, pek çok OSS git kullanıcısının takıldığı bir yerden de nefret ediyorum: Github. İlk önce bir github sayfasına gittiğinizde, yapabileceğiniz her şeyi yanınıza alıyor. Bana göre, bir git sayfasındaki projeler kaotik, korkutucu ve aşırı güçlü görünüyor. Projenin ne olduğunun açıklaması bile aşağı doğru itiliyor. Github zaten tam bir web sitesine sahip olmayan, zaten ayarlanmış olan insanları incitiyor. Sorun izleyicisi de korkunç ve kafa karıştırıcı. Özellik aşırı yükü.
Git kullanıcıları da kült gibi gözüküyorlardı. Git kullanıcıları her zaman DVCS'nin daha iyi olduğu ve daha sonra Mercurial kullanıcıları kendilerini savunmaya zorlayan “kutsal savaşları” başlatanlar gibi görünmektedir. Http://whygitisbetterthanx.com/ gibi siteler kibir ve neredeyse "Yazılımımı kullan veya öl" zihniyetini gösteriyor. Çoğu zaman, sadece X'i tanımadığım, X'i önceden kullanan, Windows'u kullanan vb.
Öte yandan, Mercurial kinder yaklaşımına doğru gidiyor gibi görünüyor. Kendi ana sayfalarında Git'e göre yeni kullanıcılar için çok daha uygun görünüyor . Basit bir Google aramada 5. sonuç, Mercurial için çok hoş bir kullanıcı arayüzü olan TortoiseHg'dir. Bütün yaklaşımları önce basitlik, daha sonra güç gibi görünüyor.
Mercurial ile SSH saçmalığım yok (SSH Windows'ta cehennem oluyor), aptalca karmaşık komutlarım yok, takip eden bir kült kullanıcım yok, çılgınlığım yok. Mercurial sadece işe yarıyor.
TortoiseHg, gerçekten kullanışlı özellikler sağlayan (son zamanlarda büyüyor gibi gözükse de) gerçekten kullanışlı bir arayüz sağlar. Seçenekler ihtiyacınız olanla sınırlıdır, karışıklığı gidermek ve nadiren kullanılan seçenekler. Aynı zamanda birçok iyi varsayılanlar sunar
Yeni gelenlere karşı çok cana yakın olan Mercurial'ı almak çok kolaydı. Farklı dallanma modeli ve tarih düzenleme gibi daha karmaşık konuların bile takip etmesi çok kolaydı. Mercurial'ı hızlı ve acısız bir şekilde aldım.
Mercurial ayrıca ilk kez küçük bir kurulumla çalışıyor. HERHANGİ bir OS'de TortoiseHg'i yükleyebilir ve farklı Guis'leri aramaya gerek kalmadan istediğim tüm özellikleri (çoğunlukla içerik menüsü komutları) alabilirim. Ayrıca eksik SSH'yi ayarlıyor (kılavuzların yarısı Putty, Plink ve Pagent kullanıyor, diğer yarısı ssh-keygen kullanıyor diyor). TortoiseHg, yeni kullanıcılar için kurulum için birkaç dakika sürerken, Git ise birçok googling ile 30 dakika ile bir saat arasında sürüyor.
Son olarak çevrimiçi repolara sahipsiniz. Githubs eşdeğeri, yukarıda ana hatlarıyla anlattığım bazı sorunların bulunduğu BitBucket. Ancak Google Kodu da var. Bir Google Kod projesine gittiğimde, aşırı özellik yükü alamıyorum, güzel ve temiz bir arayüz alıyorum. Google Code, mevcut bir site kurulumuna sahip olmayan OSS projelerine gerçekten yardımcı olan çevrimiçi bir repo / web sitesi kombinasyonudur. Projelerim web sitesi olarak Google Kodu'nu bir süredir kullanmak, ancak kesinlikle gerekli olduğunda bir web sitesi oluşturmak için kendimi çok rahat hissederim. Sorun takipçisi de Github'un neredeyse işe yaramaz Sayı İzleyicisi ile Bugzilla'nın canavarlığı arasında güzel bir şekilde uyuşan güçlü .
Mercurial sadece ilk defa, her zaman çalışır. Git yoluma çıkıyor ve sadece kullandıkça beni kızdırıyor.
Mercurial'ın genellikle Git'ten daha basit ve öğrenmesi kolay olduğuna inanılır. Buna karşılık, Git'in daha esnek ve güçlü olduğu algısı genellikle var. Bunun nedeni, Git'in daha düşük seviyeli komutlar verme eğiliminde olmasından, kısmen de varsayılan Mercurial'ın gelişmiş özellikleri gizleme eğiliminde olmasından, kullanıcıların beğenmiş oldukları gelişmiş özellikleri etkinleştirmek için ticari yapılandırma dosyasını düzenlemesini sağlamasına bağlı olmasıdır. Bu, genellikle gelişmiş özelliklerin Mercurial'da bulunmadığı algısına yol açar.
Mercurial her zaman arayüz öğrenmeye daha fazla odaklanmıştır ve bu da öğrenmeyi daha da kolaylaştırmıştır. Git'e kıyasla, Mercurial ile faydalı bir şekilde çalışmak için daha sığ bir anlayış gereklidir. Uzun vadede, böyle bir kapsülleme Mercurial'a gerçekte olduğundan daha az güçlü ve özellikli olmanın yanlış görüntüsünü verdi.
hg push --branch BRANCH
) veya belirli bir revizyona ( hg push --rev REV
) kadar basabilirsiniz . Lütfen hg help push
daha fazla seçenek için bakınız .
Bağlam: Mercurial (iş için) ve Git'i (yan projeler için ve açık kaynak) günlük olarak kullanıyorum. Öncelikle her ikisiyle de metin tabanlı araçlar kullanıyorum (IDE'lerle değil) ve Mac'tayım.
Genel olarak, Mercurial ile çalışmayı daha kolay buluyorum. Bulduğum birkaç şey Mercurial'ı kolaylaştırıyor:
hg
eşdeğer git
aslında denir bookmarks
. Bildiğim kadarıyla hg
dalların eşdeğeri yok git
.
git
dallanma bir hg
dallanma alt kümesidir . İçinde hg
hem adsız hem de adsız (topolojik) dallar olabilir ve adsız dalları da yer imleriyle aynı şekilde yönetebilirsiniz git
. Sahne alanındaki noktayı hiç görmedim. İstenmeyen değişiklikleri rafa kaldırır ve kodumun taahhüt etmeden önce testlerimi derleyip tamamladığından emin olurum. Daha sonra raftan çıkarabilir ve devam edebilirim. Ayrıca, Charles Bailey'in "Masaj Hunileri" (p90 +) beni korkutuyor * 8 '): accu.org/content/conf2011/accu2011LT_fri_share_v2.pdf
hg bookmark keyo-stuff
işleri yapma hg commit
, sonra sonunda hg push -B keyo-stuff
. Revizyon numaralarını beğenmiyorsanız, onları kullanmayın; Mercurial, bir revizyon numarasını kabul edeceği her yerde bir karma kabul edecek, sanırım. Söylemeliyim ki, aslında aslında cahil ve biraz saldırgan olarak gördüğü özelliklerin eksikliği nedeniyle Mercurial'ı temel alan yorumlarınız; Git kullanıcılarının klişeleri için çok iyi bir şey yapmıyorsunuz!
Bu çok özneldir ve bir kişiden diğerine bağlıdır, ama evet, VCS için tamamen yeni olan birisine veya "eski okul" VCS'lerden birinden gelen birine gideceğim, Mercurial daha kolay gözükecek.
Örneğin, dosya ekleme, dizinin Hg'de bulunmaması, bazı eski revizyonlara geri dönme ve oradan dallanma kolaylığı (sadece güncelleme ve taahhüt) gibi en "açık" örneklerden bazıları. Şimdi bir sistemin özelliklerinin çoğu bir başkasında taklit edilebiliyor ve bunun tersi de geçerli, ancak bu, Git'te biraz bilgi gerektirirken, Mercurial'da varsayılanlar (eğer onları çağırmama izin verirseniz) oldukça "kullanıcı dostu". Bu küçük şeyler - buradaki ve oradaki anahtar, bir komuttaki açık olmayan davranış ve bunun gibi ... bunlar bir araya gelir ve sonunda, bir sistem diğerinden daha kolay kullanılır.
Sadece cevabı tamamlamak için; Git'i kullanıyorum, ancak “yeni olanlar” için bir VCS önerdiğinde, neredeyse her zaman Mercurial'ı öneririm. Hatırlıyorum, ilk elime geldiğinde çok sezgisel hissettirdi. Benim deneyimim Mercurial'ın Git'ten daha az ağırlık / dakika üretmesi.
Sanırım bu kadar basit: Mercurial daha bilinen bir sözdizimine sahiptir (özellikle SVN kullanıcıları için) ve oldukça iyi belgelenmiştir. Git sözdizimine alışınca, onu başka bir şey kadar kolay bulabilirsiniz.
Bu konuda algılar zaman içinde değişiyor olabilir. Mercurial çok iyi tasarlanmış ve Git de öyle. Mercurial'ın öğrenmesi daha kolay görünüyor (en azından benim içindi) ve Git'te karşılaştığım, Mercurial'da paralellik göstermediğim zorluklar oldu. Python ve Ruby'yi öğrenmeye çalıştım ve Python ile daha hızlı, daha da büyüdüm. Bu Python'un her zaman ve her yerde Ruby'den daha iyi olduğu anlamına gelmez, hatta benim için daha iyi olduğu anlamına gelmez. Sadece öğrendiğim ve takıldığım şeydi. Programcılar çoğu zaman kutsal tercihleri kişisel tercihlerden çıkarırlar. Diğer insanlar da bunu yapar.
Git hakkında açık fikirli olmaya çalışan mercurial bir kullanıcıyım ve Mercurial'ınkiyle aynı derecede "yeni favori şeyim" olmadığını serbestçe itiraf ediyorum. Bence Git gerçekten çok güzel.
GIT / merkür karmaşıklığı için bir örnek: Mac'te XCode'da Nice GIT desteği var. Mercurial ile XCode'u GIT'den daha az kullanmak kolaydır.
Şimdiye kadar GIT ile olan deneyimim, kafamın karışması ve kaybolması ve kullanım sırasında belgelere daha fazla danışmam gerektiğiydi. Çok fazla dokümantasyon yazıldığına inanıyorum, fakat "grok" yapmamı sağlayacak hiçbir şey yoktu. İkincisi, Mercurial'ı Python'da kolayca değiştirebilir ve genişletebilirim, Python'da usta olduğum için ve herkes gerçekten pitonu çabucak öğrenebildiğinden, bu benim için bir avantaj gibi görünüyor. Ayrıca C'yi tanıyorum ve C'ye Python uzantılarını yazıyorum, bu yüzden bir gün gerekirse, C'ye Git uzantısını kolayca yazabileceğimi düşünüyorum.
Kullanım kolaylığı, ölçülmesi kolay bir şey değildir. O orada ve tamamen öznel olduğunu düşünmüyorum, ancak iyi objektif ölçüm tekniklerimiz yok. Kullanım kolaylığı için birim ne olurdu? Milli-iPod'lar?
% 100 mercurial ve% 100 anti-git olacak kadar partizan değilim. Şu anda Mercurial'da, Windows'ta ve Linux'ta daha rahatım ve daha fazla Mac çalışması yapmaya başladığımda, XCode + GIT'e bağlı kalmaya çalışacağımı umuyorum.
2013 Güncellemesi: Birleştirme stratejileri hakkındaki bu soru gibi Git'in sahip olmasını istediğim bazı özellikleri bulmak için yeterince Mercurial AND GIT kullandım . Gerçekten Git, öğrenmesi zor ve bazen çıldırtıcı derecede karmaşık, şaşırtıcı.
IMO'nun yeni kullanıcıları Git'ten uzak tutabileceği birkaç şey var:
Git kültürü daha komut satırı merkezli. Her iki araç da komut satırına çok fazla odaklanma eğiliminde olsa da (birkaç kez söylediğim gibi, komut satırı talimatları güçlü ve akıcı olabilir, ancak iyi bir pazarlama stratejisi değildir ) bu Git'teki durumdur. Mercurial'ın, TortoiseHg'de fiilen standart bir GUI aracı olmasına rağmen, Mercurial ana sayfasında Windows kullanıcıları için varsayılan indirme seçeneği olsa da, Git, iyi reklamı yapılmamış birçok rakip GUI ön ucuna (TortoiseGit, Git Extensions, gitk, vb.) Sahiptir. Git web sitesinde, ve zaten hepsi tamamen göz alıcı. (Kırmızı etiketlerde siyah metin var mı? Hadi, TortoiseGit, bundan daha iyisini yapabilirsiniz!) Ayrıca, Git topluluğunda GUI araçlarını kullanan kişilerin uygun yazılım geliştiriciler olmadığına dair çok daha yaygın bir tutum var.
Git, ileri düzey kullanıcılar için mükemmel olan, ancak yeni kullanıcıları korkutmuyorsa şaşırtıcı olması muhtemel birkaç varsayılan seçeneğe sahiptir. Örneğin, birleştirme gibi görevlerin otomatikleştirilmesi konusunda çok daha saldırgandır (örneğin, git pull otomatik olarak birleşir ve mümkün olduğunda taahhüt eder). Tam otomatik birleştirme için bir durum söz konusudur , ancak çoğu deneyimsiz kullanıcının birleşme korkusu vardır ve kaynak kodları üzerindeki tüm güçlerini serbest bırakmadan önce araçlarında güven kazanma fırsatı verilmelidir.
Belgeleme ve doğal karmaşıklık:
$ hg help log | wc -l
64
$ git help log | wc -l
912
Aklıma gelen tek şey
git add .
git commit -am "message"
vs.
hg ci -Am "message"
git commit -a
yeni oluşturulan dosyalar eklemiyor, hg ci -A
yapar, yani git ile iki komut gerektiren bir şey Mercurial'da bir komutla yapılabilir. Sonra tekrar, "daha az yazma" mutlaka "daha fazla kullanıcı dostu" anlamına gelmez.
git commit -a
çalışacağını tercih etmeye geldim çünkü belirli bir taahhüt için neyin eklenip neyin eklenmeyeceğini kontrol etmeyi kolaylaştırıyor. (Her için bana bireysel pathnames belirtmek için Aslında alışılmadık değil svn ci
bir taahhüt alakasız malzemeyi eklemekten kaçının.)
hg ci
olmadan -A
bayrak eşdeğer yapar git commit -a
. Git'i hg'den çok daha fazla kullandım, bu yüzden% 100 emin değilim.
hg ci
== git commit -a
.
Çünkü o.
Git, mercurial'dan çok daha fazlasını gösterir. Mercurial'ı aldıktan birkaç dakika içinde mutlu bir şekilde kullanabilirsiniz, ancak birkaç ay sonra onunla güreşmeden hemen sonra mücadele etmeyi çok zor buluyorum (son birkaç ay içinde git öğrenmeyi denemekten başka çok az şey yaptım ). Hem komut satırından hem de çoğunlukla Linux'ta kullanıyorum, bu yüzden bu sadece komut satırı arayüzünün bir tersine dönüşmesi değildir.
Basit bir örnek, git ile karşılaştırıldığında mercurial için ihtiyaç duyulan nispeten az bayrak ve komut satırı argümanlarıdır. Aşama alanı ve add komutunun git içindeki davranışı da gerekenden daha fazla karmaşıklık sağlar. Sıfırlama, satın alma ve geri alma üçlüsü ve bunların çoklu permütasyonları, geri dönüşün doğrudan doğasına tanık olduğunuz ve merküryal üzerine güncellediğiniz zaman çok gereksiz olan muazzam bir karmaşıklık ekler.
Hginit hakkındaki yukarıdaki yorum ile aynı fikirdeyim , kesinlikle daha kolay anlaşılması çok daha kolay. İyi yazılmış ve anlaşılması çok kolay. Git için yazılan hiçbir belge yaklaşmıyor. Birincisi, Scott Chacone'nin yazdığı çoğu şeyi (kim git gitle ilgili belgelerin / kitapların çoğunu tek başına yazdığını) özellikle kafa karıştırıcı buluyorum.