it-swarm.asia

Mercurial'ın Git'ten neden daha kolay olduğu düşünülüyor?

Karşılaştırmaya baktığımda, özellik kümeleri arasında 1: 1 eşleme olabileceği anlaşılıyor. Yine de, sıkça atıfta bulunulan bir ifade "Mercurial daha kolaydır" dır. Bu ifadenin temeli nedir? (varsa)

204
Tamás Szelei

Burada örnek: Diyelim ki önceki tüm işlemlerinizde kullanıcı adını değiştirmek istiyorsunuz. Bunu çeşitli nedenlerle 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 "[email protected]";
        else
                git commit-tree "[email protected]";
        fi' HEAD

Mercurial Versiyon:

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: Ben sadece Git ile çalışarak 2 yıl geçirdim, bu yüzden bu "Nefret ediyorum, 2 saniye içinde alamadım" rant değil.

Benim için kullanılabilirlik. Git, linux tarzı bir şeyler yapmak için çok linux odaklı. Bu komut satırı, man sayfaları ve kendiniz bulmak anlamına gelir. Çok kötü bir GUI vardı (not: Ben msysGit bunu yaklaşık bir yıl önce temel alıyorum), bu sadece benim yolumda gibi görünüyordu. Zar zor kullanabildim

Komut satırı daha kötüydü. Linux odaklı bir program olarak, Windows'da kullanımı çok zordu. Yerel bir liman yerine git ile MinGW (Think cygwin) ile sarıldılar, bu da onunla çalışmayı çok daha zor hale getirdi. MinGW, Windows Komut İstemi değildir ve farklı davranır. Git ile çalışmanın tek yolu bu. Linux'ta bile tek yol düz komut satırı ile çalışmak gibiydi. RabbitVCS gibi projeler bazılarına yardımcı oldu, ancak çok güçlü değildi.

Komut satırı odaklı yaklaşım ve linux programı olmak, neredeyse tüm nasıl yapılır kılavuzlarının, yardım belgelerinin ve forum/QA sorularının yukarıdaki gibi korkunç komutlar çalıştırmaya bağlı olduğu anlamına geliyordu. Temel SCM komutları (kaydetme, çekme, itme) o kadar karmaşık değildir, ancak daha fazla ve karmaşıklık katlanarak büyür.

Ayrıca OSS git kullanıcılarının bir sürü takıldığı bir yerden nefret ediyorum: Github. Bir github sayfasına ilk kez gittiğinizde, yapabileceğiniz her şeyi size vurur. Bana göre bir proje git sayfası kaotik, korkutucu ve aşırı güçlü görünüyor. Projenin ne olduğuna dair açıklama bile aşağıya doğru itiliyor. Github, zaten tam web sitesi olmayan insanlara zarar veriyor. Sorun izleyicisi de korkunç ve kafa karıştırıcı. Özellik aşırı yüklenmesi.

Git kullanıcıları da kült gibi görünüyordu. Git kullanıcıları her zaman DVCS'nin daha iyi olduğu "kutsal savaşlara" başlayanlar gibi görünüyor ve bu da Mercurial kullanıcılarını kendilerini savunmaya zorluyor. http://whygitisbetterthanx.com/ gibi siteler kibir ve neredeyse "Yazılımımı kullan ya da öl" anlayışını gösterir. Birçok kez sadece X bilmemek, önceden X kullanmak, Windows kullanmak, vb için alev almak için çeşitli yerlere gittim. Bu çılgınca.


Öte yandan Mercurial kinder yaklaşımına doğru gidiyor gibi görünüyor. Kendi ana sayfa yeni kullanıcılar için Git'in 'den çok daha kolay görünüyor. Basit bir Google aramasında 5. sonuç, Mercurial için çok güzel bir GUI olan TortoiseHg'dir. Tüm yaklaşımları önce basitlik, daha sonra güç gibi görünüyor.

Mercurial ile SSH saçmalık yok (SSH Windows'ta cehennem), aptalca karmaşık komutlarım yok, takip eden bir kült kullanıcım yok, delilik yok. Mercurial işe yarıyor.

TortoiseHg, gerçekten kullanışlı özellikler sağlayan (son zamanlarda büyüyor gibi görünse de) gerçekten kullanılabilir bir arayüz sağlar. Seçenekler, gereksiniminizle sınırlıdır, dağınıklığı ve nadiren kullanılan seçenekleri kaldırır. Ayrıca çok iyi varsayılanlar sağlar

Mercurial, yeni gelenlere çok arkadaşça davranmak çok kolaydı. Farklı dallanma modeli ve tarih düzenleme gibi daha karmaşık konuların bile takip edilmesi çok kolaydı. Mercurial'ı hızlı ve acısız bir şekilde aldım.

Mercurial ayrıca ilk kez küçük kurulumlarla çalışır. HERHANGİ BİR OS'de TortoiseHg'yi kurabilir ve farklı Guis'leri aramak zorunda kalmadan istediğim tüm özellikleri (esas olarak bağlam menüsü komutları) alabilirim. Ayrıca eksik SSH (diğer kılavuzların ssh-keygen kullandığını söylerken, kılavuzların yarısı PuTTY, Plink ve Pagent kullandığını söylüyor). Yeni kullanıcılar için, TortoiseHg'nin kurulumu birkaç dakika sürer, Git ise çok fazla googling ile 30 dakika ila bir saat sürer.

Son olarak çevrimiçi depolara sahipsiniz. Githubs eşdeğeri, yukarıda özetlediğim bazı sorunlara sahip BitBucket. Ancak Google Code da var. bir Google Code projesi , özellik aşırı yük alamadım, Güzel temiz bir arayüz olsun. Google Code, mevcut bir site kurulumu olmayan OSS projelerine gerçekten yardımcı olan bir çevrimiçi repo/web sitesi kombinasyonudur. Google Code'u oldukça uzun bir süredir projelerimin web sitesi olarak kullanmak beni çok rahat hissediyordu. Sorun izleyicisi de güçlü, Github'un neredeyse işe yaramaz Sorun İzleyicisi ve Bugzilla'nın canavarlığı arasına iyi uyuyor.

Mercurial her seferinde ilk kez çalışır. Git yoluma giriyor ve beni ne kadar çok kullanırsam o kadar sinirliyor.

240
TheLQ

Git Mercurial'a Karşı

Mercurial'ın genellikle Git'ten daha basit ve öğrenmesi daha kolay olduğuna inanılıyor. Buna karşılık, Git'in daha esnek ve güçlü olduğu algısı sıklıkla vardır. Bunun nedeni kısmen Git'in daha düşük seviyeli komutlar sağlama eğiliminde olması, ancak kısmen de kısmen varsayılan Mercurial gelişmiş özellikleri gizleme eğiliminde olmasıdır , beğendikleri gelişmiş özellikleri etkinleştirmek için Mercurial yapılandırma dosyasını düzenlemelerini kullanıcılara bırakarak. Bu genellikle Mercurial'da gelişmiş özelliklerin bulunmadığı algısına yol açar.

Git Kavramları

Mercurial her zaman daha çok arayüz yönlerine odaklanmıştır, bu da aslında öğrenmeyi kolaylaştırır. Git ile karşılaştırıldığında, Mercurial ile faydalı bir şekilde çalışmak için daha sığ bir anlayış gerekir. Uzun vadede, böyle kapsülleme Mercurial'a gerçekte olduğundan daha az güçlü ve özellikli olmanın yanlış görünümünü vermiştir.

80
Cyclops

Bağlam: Günlük olarak hem Mercurial (iş için) hem de Git (yan projeler ve açık kaynak için) kullanıyorum. Öncelikle metin tabanlı araçları hem IDE'lerle hem de Mac'te kullanıyorum.

Genel olarak, Mercurial ile çalışmayı daha kolay buluyorum. Bulduğum birkaç şey Mercurial'ı kolaylaştırıyor:

  1. Dizin eksikliği. Dizin, Git'in birçok özelliğini sağlayan güçlü bir araçtır, ancak düzenli olarak yaptığım birçok şeye bir adım ekleyen ekstra bir katmandır. Mercurial'ın iş akışı svn gibi bir şeye daha benzer.
  2. shas yerine revizyon numaraları. Bu bulduğum küçük bir şey Mercurial'da günlük komutlarla çalışmayı çok daha kolay hale getiriyor. Bir komut yazarken birkaç revizyon numarasını bir yeniden yazma, birleştirme vb. Sırasında başınıza itmek, kısaltılmış shas ile aynı şeyi yapmaktan daha kolaydır.
  3. Şubeler. Git'in taahhütleri adlandırarak şubelere yaklaşımı güçlü ve diğer sürüm kontrol sistemlerinden önemli ölçüde farklı. Bazı şeyleri çok daha kolay hale getirir. Mercurial'ın yaklaşımının svn düşüncesiyle biraz daha iyi eşleştiğini ve şube geçmişini görsel olarak anlamayı kolaylaştırdığını düşünüyorum. Bu sadece bir tercih olabilir.
47
Alex Miller

Bu çok özneldir ve bir kişiden diğerine bağlıdır, ancak evet, VCS'ye tamamen yeni birine veya "eski okul" VCS'lerinden birisine gelen birine gideceğim, Mercurial daha kolay görünecek.

Örneğin, dosya ekleme, Hg'de indeksin olmaması, bazı eski revizyonlara geri dönme ve oradan dallanma kolaylığı (sadece güncelleme ve taahhüt etme) en "açık" örneklerden bazıları olarak. Şimdi bir sistemin özelliklerinin çoğu diğerine benzetilebilir ve bunun tersi de geçerlidir, ancak bu Git'te biraz bilgi gerektirir, Mercurial'da ise varsayılanlar (bunları çağırmam için izin verirseniz) oldukça "kullanıcı dostudur". Bu küçük şeyler - burada ve orada geçiş, bir komutta açık olmayan davranışlar vb. Bu şeyler toplanır ve sonunda bir sistemin kullanımı diğerinden daha kolay görünür.

Sadece cevabı tamamlamak için; Git kullanıyorum, ama "onlar için yeni" biri için bir VCS tavsiye ederken, neredeyse her zaman Mercurial tavsiye ederim. Hatırlıyorum, ellerime ilk geldiğinde çok sezgisel geldi. Benim tecrübem, Mercurial'ın Git'ten daha az ağırlık/dakika üretmesi.

29
Rook

Bence bu kadar basit: Mercurial daha tanıdık bir sözdizimine sahiptir (özellikle SVN kullanıcıları için) ve oldukça iyi belgelenmiştir. Git sözdizimine alıştıktan sonra, her şeyi kullanmak kadar kolay bulacaksınız.

17
pdr

Bu konuda algılar zamanla 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 olmadığım zorluklar vardı. Python ve Ruby öğrenmeye çalıştım ve Python ile daha da hızlılaştım. Bu Python her zaman ve her yerde Ruby'den daha iyi, hatta benim için daha iyi olduğu anlamına gelmez. Sadece öğrendiğim ve takılıp kaldım. Programcılar genellikle kişisel tercihler dışında kutsal savaşlar yaparlar. Diğer insanlar da bunu yapar.

Ben Git hakkında açık fikirli olmaya çalışan bir Mercurial kullanıcısıyım ve Mercurial ile aynı ölçüde "benim en sevdiğim şey haline gelmediğini" serbestçe itiraf ediyorum. Bence Git gerçekten çok güzel.

GIT/Mercurial karmaşıklığı için karşı bir örnek: Güzel GIT desteği Mac'te XCode'a yerleştirilmiştir. Mercurial ile kullanımı kolay XCode'u GIT'den daha az.

Şimdiye kadar GIT ile yaşadığım deneyim, kafanın karışması ve kaybolması ve kullanırken belgeleri daha fazla incelemeye gitmem gerekti. Çok fazla dokümantasyonun yazıldığına inanıyorum ama bana "grok" yapmamı sağlayan hiçbir şey yok. İkincisi, Mercurial'ı Python'da kolayca değiştirebilir ve genişletebilirim ve Python'da usta olduğum için ve herkes gerçekten python hızlı bir şekilde öğrenebileceğim gibi, benim için bir avantaj gibi görünüyor. ve Python uzantıları yazın, bu yüzden bir gün, sanırım bir güne ihtiyacım olursa, C'de kolayca bir Git uzantısı yazabilirim.

Kullanım kolaylığı, ölçülmesi kolay bir şey değildir. Orada ve tamamen öznel olduğunu düşünmüyorum, ama iyi objektif ölçüm tekniklerimiz yok. Kullanım kolaylığı için birimler ne olurdu? Milli-iPod'lar?

Ben% 100 Mercurial yanlısı ve% 100 anti-git olacak kadar partizan değilim. Mercurial'da şu anda, Windows'da ve Linux'ta daha rahatım ve daha fazla Mac çalışması yapmaya başladığımda, XCode + GIT ile çalışmaya çalışacağımı umuyorum.

2013 Güncellemesi: Artık Mercurial AND GIT'i Git'in sahip olmasını istediğim bazı özellikleri bulmak için yeterince uzun süre kullandım, örneğin b birleştirme stratejileri hakkında soru. Gerçekten Git, öğrenmesi zor ve bazen de şaşırtıcı derecede karmaşık.

9
Warren P

IMO'nun yeni kullanıcıları Git'ten kaldırması muhtemel birkaç şey vardır:

  1. Git kültürü daha çok komut satırı merkezlidir. 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 ) Git için durum çok daha fazla. Mercurial, Mercurial ana sayfasındaki Windows kullanıcıları için varsayılan indirme seçeneği olan TortoiseHg'de fiili bir standart GUI aracına sahipken, Git'in iyi reklamı yapılmayan birkaç rakip GUI ön ucu (TortoiseGit, Git Uzantıları, gitk, vb.) Git web sitesinde ve bunların hepsi de tam bir göze batan şey. (Kırmızı etiketlerde siyah metin var mı? Hadi, TortoiseGit, bundan daha iyisini yapabilirsiniz!) Git topluluğunda GUI araçlarını kullanan kişilerin uygun yazılım geliştiricileri olmadığı konusunda çok daha yaygın bir tutum var.

  2. Git, ileri düzey kullanıcılar için mükemmel bir anlam ifade eden, ancak yeni kullanıcılara gözdağı vermiyorsa şaşırtıcı olacak birkaç hazır varsayılana sahiptir. Örneğin, birleştirme gibi görevleri otomatik hale getirme konusunda çok daha agresiftir (örneğin, git pull otomatik olarak birleşir ve mümkün olduğunda devreye girer). Tam otomatik birleştirme için bir durum vardır , ancak deneyimsiz kullanıcıların çoğu birleştirilmekten korkuyor ve kaynak kodlarında tam güçlerini açmadan önce araçlarına güven kazanma fırsatı verilmesi gerekiyor.

  3. Dokümantasyon ve doğal karmaşıklık:

    $ hg help log | wc -l
    64
    $ git help log | wc -l
    912
    
7
jammycakes

Çünkü o.

Git, Mercurial'dan çok daha fazla cesaretini ortaya koyuyor. Mercurial'ı aldıktan sonra birkaç dakika içinde mutlu bir şekilde kullanabilirsiniz, ancak birkaç ay güreşten sonra gitmeyi çok zor buluyorum (git öğrenmeye çalışmak dışında son birkaç ay içinde çok az şey yaptım ). Hem komut satırından hem de çoğunlukla Linux'ta kullanıyorum, bu sadece komut satırı arayüzüne bir kaçınma değil.

Basit bir örnek Mercurial için git ile karşılaştırıldığında nispeten az sayıda bayrak ve komut satırı argümanlarıdır. Git komutundaki hazırlama alanı ve add komutunun davranışı da gereğinden fazla karmaşıklık katıyor. Sıfırlama, ödeme ve geri alma üçlüsü ve çoklu permütasyonları, Mercurial'ta geri dönmenin ve güncellemenin doğrudan doğasına tanık olduğunuzda oldukça gereksiz olan çok büyük bir karmaşıklık ekler.

Yukarıdaki yorumu da kabul ediyorum Hginit , Mercurial'ı anlamak çok daha kolay oldu. İyi yazılmış ve anlaşılması çok kolay. Git için yazılan belgelerin hiçbiri yaklaşmıyor. Birincisi, Scott Chacone tarafından yazılanların çoğunu (kim gittikçe belgelerin/kitapların çoğunu git hakkında yazdı) özellikle kafa karıştırıcı bul.

3
haziz

Aklıma gelen bir şey var

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'ta bir komutla yapılabilir. Sonra tekrar, "daha az yazım" mutlaka "daha kullanıcı dostu" anlamına gelmez.

3
Zhehao Mao