Mercurial neden Git'ten daha kolay kabul edilir?


204

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)


21
Garip, Mercurial'ın daha kolay olduğunu hiç duymamıştım. Git için daha fazla belge buldum (algılanmış olabilir) bu yüzden öğrendim.
Nic

16
Linus tarafından yapıldığı için mi?
İş

124
Burada kutsal bir savaş alanına girmeyi tercih ettim, ama Mercurial'ı Git'ten daha kolay buldum çünkü bir Windows kullanıcısı olarak Mercurial'dan hoşlandığımı ve Git'in tuhaf ve kaybeden olduğunu düşündüm. Antropomorfize edici bir yazılım olduğumu biliyorum ve her ikisinin de Windows altında gayet iyi kullanılabildiğini biliyorum, ancak bu ikisi tarafından ortaya konulan izlenim.
Carson63000


11
Github olmasaydı ya da o kadar çok yüksek profilli projesi olmasaydı Git'i kaç kişinin kullanacağını merak ediyorum?
Chris S,

Yanıtlar:


240

Ö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.


6
Yorum yapanlar : yorumlar, uzun tartışmalar için değil, açıklama arayışı içindir. Bir çözüm varsa, bir cevap bırakın. Çözümünüz zaten yayınlandıysa, lütfen geçersiz kılın. Bu soruyu başkalarıyla görüşmek isterseniz, lütfen sohbeti kullanın . Daha fazla bilgi için SSS bölümüne bakın .

1
IntelliJ IDEA ve Xcode 4 Git ile kendi platformlarında harika bir entegrasyona sahiptir ve günlük işler için komut satırını kullanmak zorunda kalmazsınız.

4
GIT'yi pencerelerde kullanmak istediğinizde, şimdi tortoiseGIT'in daha iyi olduğunu eklemek isterim. Yine de SSL tuşlarıyla uğraşmak zorundasınız ve kurulum işlemi sorunsuz değil, ancak işiniz bitince kolayca çalışıyor.
Arkh

2
Git Uzantıları Gezinme ve birlikte çalışma konusunda kişisel olarak pencerelerde TortoiseHG'den daha kolay buluyorum ve şimdiye kadar sadece git komutuyla sadece 1 komut satırı kullandım.
KallDrexx

1
Bu çizgiden şaşırdım: "MinGW, Windows Komut İstemi değil ve sadece farklı davranıyor. Git ile çalışmanın tek yolu bu delilik." Windows komut satırından çalıştırmak için msysgit kurulumunu ve seçenek 2'yi kullanıyorum. İyi çalışıyor. İşe yaramayan birkaç şey (şapka gibi, DOS'ta bir satır devam karakteri) ama iyi çalışanlara alternatifler var (tilde gibi). Komut satırı meraklısı değilim (ya da en azından Git'i öğrenmeye başlamadan önce değildim) ama Git'i komut satırıyla kullanmak gerçekten kolay. Bir şey mi eksik?
Kyralessa

80

Git ve Mercurial'a karşı

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.

Git Kavramları

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.


73
Bu yüzden Mercurial yalnızca gelişmiş işlevleri gizlerken, GIT tüm işlevleri gizler ... ;-)
awe

4
Git gelmez fazla güce sahiptir. Örneğin git'in HEAD ~ 1'ine eşdeğer yoktur . Mercurial'ın dallar arasında yayılan p (x) değeri ne kadar işe yaramaz. Hg'de aşama yok. İttiğinizde tüm dallara basılmalıdır. Mercurial, histedit, raf ve rebase gibi tüm eklentilerde bile esnek değildir. Git'in komut satırı da daha iyi, kullanıcılara ipucu veriyor, mercurials değil. İşyerinde bu hafif sakatlı DVCS'yi kullanmaya zorlanıyorum ve mercurial'ın istediğimi yapma gücüne sahip olmadığı durumlara girdim.
Keyo

22
@Keyo: Mercurial vardır ~, bakınız revsets . Bir evreleme alanına sahip değildir, ancak çok daha güçlü olan MQ ile öykünebilirsiniz. Git'ten bildiklerinize bağlı kalmak yerine bu aracı kullanmayı öğrenin.
Idan K,

22
@Keyo: Bastığınız zaman tüm dalları Mercurial ile itmeniz gerekmez. Belirli bir dalı ( hg push --branch BRANCH) veya belirli bir revizyona ( hg push --rev REV) kadar basabilirsiniz . Lütfen hg help pushdaha fazla seçenek için bakınız .
Regent,

1
Bilginize, bir kayıt uzantısı kullanarak evreleme alanının önemli bir alt kümesini alabilirsiniz . OTOH, bence raf uzatması (Baazar'ın "raf" komutundan sonra modellenmiş ve "git stash" a yakın) modellendirme alanını kullanma amaçlarının çoğunda daha iyi hizmet veriyor.
brandizzi

47

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:

  1. Endeks eksikliği. Dizin, Git'in birçok özelliğine olanak sağlayan güçlü bir araçtır, ancak aynı zamanda düzenli olarak yaptığım pek çok şeye bir adım ekleyen fazladan bir katmandır. Mercurial'ın iş akışı svn gibi bir şeye daha benzer.
  2. Shas yerine revizyon numaraları. Bu, Mercurial'da her gün komutlarla çalışmayı çok daha kolay hale getiren küçük bir şey. Yeniden düzenleme, birleştirme, vb. Sırasında bir komut yazarken birkaç revizyon rakamını kafanıza itmek, kısaltılmış shas ile aynı işlemi yapmaktan daha kolaydır.
  3. Dallar. Git'in komisyonları adlandırarak şubelere yaklaşımı güçlü ve diğer sürüm kontrol sistemlerinden büyük ölçüde farklı. Bazı şeyleri çok daha kolaylaştırır. Mercurial'ın yaklaşımının svn ile biraz daha iyi düşünmekle eşleştiğini ve şube tarihini görsel olarak anlamayı kolaylaştırdığını biliyorum. Bu sadece bir tercih olabilir.

6
Endeksi belirtmek için +1; Ben endeksi düşünmek ve onun etkileşimleri vardır git daha zor cıva daha fazla bilgi edinmek için yapan şey.
Sean McMillan

18
Dallara hgeşdeğer gitaslında denir bookmarks. Bildiğim kadarıyla hgdalların eşdeğeri yok git.
Hank Gay,

6
Aynı durumdayım, işte mercurial, evde de git. Mercurial dallanma beni rahatsız ediyor, özel şubelerim olmasını ve istediğimde onları zorlamasını seviyorum. Mercurial beni raf veya ek depo kullanmaya zorlar. Revizyon numaraları saçma, bana hash ver. Aşamada sahne harika, bunu özlüyorum. Git'in gücünü gerçekten çok özlüyorum. Bazı eklentileri ile birkaç şey yaptım ama dallanma beni gerçekten sinir ediyor.
Keyo

6
@Keyo - Benim tecrübeme göre, gitdallanma bir hgdallanma alt kümesidir . İçinde hghem 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
Mark Booth

7
@Keyo: Mercurial'da, özel dallara 'yer imleri' adı verilir: kök revizyonuna güncelleme , sonra hg bookmark keyo-stuffiş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!
Tom Anderson,

29

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.


"% Wtf / dakika" için +1 "Bu çok öznel" içindir. Çok öznel değil ... İnsanların neden UI farklılıklarının öznel olduğunu düşündüğünü bilmiyorum. Mercurial ve md5 karma komutlarını alırsam, bazılarının md5 karma değerini orijinalden daha sezgisel bulabileceği tartışmasını yapmazsınız, değil mi? (Umarım değildir). Aynısı Git için de geçerlidir. Git, git ile olan deneyiminiz mercurial'dan çok daha önemliyse, mercurial'dan daha kolaydır.
weberc2 21:13

17

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.


7
Hayır! Yalnızca "farklı sözdizimi" olarak adlandırmanız için çok fazla iş akışı adımı var. Git'i kullanmak için manipüle ettiğiniz modeli ve git indeksinin tüm durumunu anlamak zorundasınız. SQL ve Pascal’ın aynı şey için iki farklı sözdizimi olduğunu söylemek eşit derecede yanlış olur. Git, DVCS özelliklerine sahip bir dosya sistemi içerik versiyonlama sistemidir. Mercurial, GIT'in yaptığı her dosya sistemi içerik oluşturma işlemini yapmayan bir DVCS'dir, yalnızca DVCS kullanıcılarının ihtiyaç duyduğu altkümedir.
Warren P,

9

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ı.


7

IMO'nun yeni kullanıcıları Git'ten uzak tutabileceği birkaç şey var:

  1. 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.

  2. 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.

  3. Belgeleme ve doğal karmaşıklık:

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

3
Aslında, 912 satır uzunluğunda bir yardım için 64 olan bir yardım tercih ediyorum.
Dysaster

10
Aslında, ilk bakışta yardıma ihtiyacınız olmayacak kadar sezgisel ve kusursuz bir kullanıcı arayüzü tercih ediyorum.
jammycakes

2
Hem GUI hem de yardım istiyorum. :) Bana sezgisel görünen, başkası için bir karmaşa.
Dysaster

1
Elbette, ancak yardım gerektiğinde takip etmesi kolay olmalıdır.
jammycakes

3
Yeni bir benzetme düşündüm; Git C ++ 'a (üzgünüm Linus!) Ve Mercurial Pascal'a benziyor. Kapalı ve Pascal'da (ya da Mercurial'da yalnızca bir yolla yapılabilir) açıkça, C ++ (ve Git) 'de on dokuz farklı yolla yapılabilir. Bazı insanlar daha fazla düğme ve kol olan powertools'u tercih ediyor ve Git de öyle.
Warren P,

3

Aklıma gelen tek şey

git add .
git commit -am "message"

vs.

hg ci -Am "message"

git commit -ayeni oluşturulan dosyalar eklemiyor, hg ci -Ayapar, 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.


11
Sık sık iş akışımda otomatik olarak yeni dosyalar eklemenin aslında istenmeyen olduğunu fark ediyorum . Nasıl 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 cibir taahhüt alakasız malzemeyi eklemekten kaçının.)
greyfade

3
Yeterince adil, ama ben inanıyorum hg ciolmadan -Abayrak eşdeğer yapar git commit -a. Git'i hg'den çok daha fazla kullandım, bu yüzden% 100 emin değilim.
Zhehao Mao

Kontrol ettik, hg ci== git commit -a.
Zhehao Mao

ancak hg commit ile belirli dosyalar belirlerseniz istemediklerinizi almaktan kaçınabilirsiniz. Bu kontrolü istediğim nadir durumlarda, bunun iyi sonuç verdiğini biliyorum.
Alex Miller,

1
neden "git ekleyeceksin"? ve sonra "git commit -am"? Her şey dizine zaten eklenmedi mi?
jacobangel

3

Çü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.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.