Son yıllarda Git etrafındaki aldatmaca büyük ölçüde arttı. Git'i herkes biliyor, alternatifleri kimse bilmiyor.
Mercurial gibi diğerleri fark edilmiyor gibi görünüyor. Her ikisi de 2005 yılında piyasaya sürüldü ve benzer işlevler sağladı. Dahası, Mercurial'ın kullanımı daha kolay, daha sezgisel ve uzun süredir daha iyi kullanıcı arayüzlerine sahip olduğu düşünülmektedir. Bu nedenle, bunun özellikle dağıtılmış sürüm kontrolüne yeni başlayanlar için popüler bir alternatif olacağı varsayılabilir. Yine de, oldukça başarılı olan Git'in aksine çoğu insan tarafından bilinmemektedir.
Bu yazının amacı bu olguyu daha iyi anlamaya çalışmaktır.
Git pastanın tamamını nasıl alır? Bir şekilde daha iyi pazarlama kullandılar mı? Çünkü topluluğu daha ... ahem ... "ayrıntılı" mı? "Linus" ismi yüzünden mi? Geeky görüntüsü yüzünden mi?
Senin düşüncen nedir?
Mercurial için, DVCS popüler olduğunda böyle bir hizmet yoktu (en azından hiçbiri farkında değildim). Bitbucket şimdi ve muhtemelen başkaları var, ama GitHub bir süredir orada, tanınmış ve daha iyi ve daha iyi oluyor.
Buna, yazarın bir veya diğer SCM'yi duyurken sahip olduğu duygulara dayanan birçok cevap görüyorum. Diğerleri her şeyin tamamen şans olduğunu söylüyor. Şansın tarihe kadar izlenebileceğine inanıyorum.
Tarih hakkında konuşacağım.
Git ve Mercurial aynı sorunu çözmek için aynı anda oluşturuldu. O günlerde, Linux çekirdeği, 3 yıldır kullanmakta olduğu tescilli dağıtılmış bir SCM olan BitKeeper'ı kullanmayı bırakmak zorunda kaldı. Bunun nedeni, BitKeeper'ın arkasındaki şirket olan BitMover CEO'su Larry McVoy'un yazılımını Linux geliştiricilerine ücretsiz olarak vermeyi bırakmasıydı, çünkü Linux topluluğunun içindeki bir kişi bunu tersine değiştirmişti.
Zaten var olanlardan memnun olmayan Linus Torvalds, daha sonra yakında Git adını vereceği yepyeni bir SCM üzerinde çalışmaya başladı. Hemen ardından Matt Mackall, Mercurial projesine benzer nedenlerle başladı.
Bir süre sonra bu projeleri ayrı ayrı geliştirdikten sonra, Matt Mackall SCM'nin gelişmiş bir versiyonunu sundu ve onu (sadece birkaç haftalık olan Git) ile karşılaştırarak belirli bir şekilde kıyasladı. Linus Git yerine kullanmayı düşündü Çekirdek gelişimi için düşünmüş, ancak Mercurial, revizyon değişikliklerini günlüğe kaydetmek için Değişiklik Kümeleri kullandığını anladı . Bunun BitKeeper'ın çalışma biçimine çok yakın olduğundan korkuyordu ve kesinlikle birisinin "BitKeeper klonu oluşturdular" diyebilecek hiçbir şey istemiyordu.
Bu nedenle Git, Mercurial yerine Çekirdek gelişimi için kullanıldı, ancak her ikisi de teknik olarak anlamlıydı. Sonuç olarak Git aslında kullanılmak üzere tasarlandığı yerde kullanılmakla başladı, Mercurial ise ilk büyük FOSS kullanımını bulmak kadar hızlı değildi. Çok iyi bir tasarıma sahip olduğu ve Matt Mackall'un azmi sayesinde, sonunda ünlendi ve büyük, gerçek dünyadaki projeler için kullanıldı.
Bugün ikisi de ünlü. Hangisinin en ünlü olduğunu söylemek imkansız. Google Code, Git'i yalnızca yakın zamanda entegre ederken, Mercurial uzun süre kullanmıştı. Gerçekten büyük ve ünlü birçok proje de kullanıyor.
Ne demek istediğimi anlıyorum, bir projeye başlamanızın nedeni ortadan kalktığında, popülerlik kazanmak daha zor ama yine de uygulanabilir.
Çarşı GNU dünyasında çok ünlü olan ama bunun dışında çok fazla olmayan bir başka SCM), çünkü GNU topluluğunu tatmin etmek amacıyla oluşturulmuştur. Yazılım genellikle içerik oluşturucularının gitmek istedikleri yere gider, başka yere gitmez.
Öte yandan, dağıtılmış SCM'ler açık kazananlardır. Orada çok yaygın olarak dağıtılmamış SCM'ler görmüyorum.
Linus Torvalds
Linus, Git'in büyük bir savunucusudur ve onu yıllarca çekirdek linux grubuna yükseltti ve oradan yetiştirildi. Tamamen Linus'un * nix topluluğu üzerindeki etkisinden kaynaklanıyor.
Şahsen Subversion'u kullanıyorum, ama bu faydadan çok tercih ediliyor.
Versiyon kontrol sistemli genel ağrı noktası şube birleştirmedir .
Olmak için ne kadar acı verici olabileceğini ve çalışmanın ne kadar önemli olduğunu anlamak için çalışmadığında denemeniz gerekir. dalları ile serbestçe çalışma.
Linus Torvalds'ın bunu doğru yapmak için git yazdığını ve bir durumda git'i on iki dalı bir kerede birleştirmek için kullandığını iddia ettiği için, bu bir Git'in ilginç olması için çok ikna edici bir argüman.
Yaklaşık bir yıl önce hg ve git arasında seçim yapmak zorunda kaldım ve yukarıdaki birleştirme git seçiminde önemli bir faktördü. İkincisi, Eclipse organizasyonunun git'e geçmesiydi, bu yüzden Eclipse takımının Java projeleri için iyi olması bekleniyordu. Eclipse 3.7'nin piyasaya sürülmesi ile bu gerçekleşti. Belki 6-9 aydık) erken.
Farklı ihtiyaçlar için hg de aynı derecede faydalı olabilir. Sun, VCS'lerini çok dikkatli bir araştırmaya dayanarak seçti. Teknik incelemeleri bulmak ve gerekçelerinin ne olduğunu görmek isteyebilirsiniz.
DÜZENLEME: Not, Mercurial'ın yapamayacağı bir şey olmadığını söylemiyorum, sadece Java - birincil odak noktamız) - piyasa güçleri şu anda Windows için bile git için en güçlü ve ayaklarının değil, başkalarının omuzlarında durmalıyız.
Git veya Mercurial'ın neden daha iyi olduğunu söylemek ve popüler olmasının tek nedeni olduğunu söylemek yerine topluma odaklanacağım.
Ben daha önce vurgulanmış olarak, Git topluluğu çok gürültülü ve kibirli. Çoğu değerli programlarını şiddetle savunacaktır. Gördüğüm Git vs Mercurial savaşlarının çoğu, Dünya'daki herkesin neden kutsal git'i kullanmadığını merak eden git insanlar tarafından başlatıldı. whygitisbetterthanx.com gibi siteler, başkalarını alevlendirmek için yazılan girişte bu kibriyi bile gösterir.
Herkesin bu şekilde olduğunu söylemiyorum, ama çoğu zaman git insanları, pro-git web siteleri ve git gibi hissettiğim pro-git blogları ile karşılaştığımda, uygulanabilir bir DVCS olarak sunulan yerine boğazımdan aşağı itiliyordu sistemi.
Buna karşılık, diğer DVCS toplulukları o kadar yüksek değildir. Mercurial'ın "En iyi DVCS nedir?" SO üzerinde soru. Git her yerde görünürken, diğer DVCS'lerin bulunması zaman alır.
Mercurial'ın özellikle düşük profilli olduğunu düşünmüyorum. Fırın Hg üzerine kurulmuştur ve bir süredir Eclipse & Netbeans gibi IDE'lerde iyi bir destek olmuştur.
Konuştuğum geliştiricilerin çoğu, daha iyi Windows desteği nedeniyle Hg'yi tercih ediyor gibi görünüyor. Eğer Linux geliştiricileri olsaydık farklı bir hikaye olabilirdi.
Ayrıca gerçek "unutulmuş DVCS" olan "Bazaar" ı da kaçırıyorsunuz.
Kesinlikle Linus'un çok karizmatik bir adam ve neredeyse eşit olmayan bir alfa inek olduğunu kabul ediyorum, bu yüzden birçok insan bu nedenle Git'e yönelirdi. Ayrıca, Git'in "Yaratılış efsanesi", Git'i oluşturmak ve yedincide dinlenmek için 6 gün boyunca Linus emeği ile çok zorlayıcı - ya da bunun gibi bir şey. Bir ürünün unutulmaz bir hikayesi olduğunda çekiş kazanmak daha kolaydır.
Bu mütevazı bir görüş, ama git iki parametre nedeniyle tüm bu yutturmaca alabilir:
Ayrıca, git github gibi katil bir uygulama aldı ve bazı çok popüler projeler onu kullanmaya karar verdi, bu da çok fazla görünürlük sağladı.
Esas olarak sadece kendini güçlendiren yutturmaca. Git en popüler olanıdır, bu yüzden en popüler olanı alır, bu da daha popüler hale gelir.
Git, Hg ve Bzr hepsi mükemmel derecede iyi DVCS sistemleridir, ancak korkutucu sayıda insan DVCS'yi Git ile eşitler ve bir DVCS'nin tüm güzel özelliklerinin Git'e özgü olduğunu düşünür. Ve böylece Git'i kullanıyorlar ve Git'i tavsiye ediyorlar ve "Git daha iyi çünkü ahtapot birleşmeleri yapabiliyor" (Çarşı da yapabiliyor) ya da "Git dağıtıldığından daha iyi" gibi şeyler söylüyorlar (= any DVCS, dolayısıyla adı) veya "Git daha iyi, çünkü dallanma ve birleştirmeyi kolaylaştırıyor" (yine her DVCS için geçerlidir).
Ne yazık ki, alternatiflerin de sunabileceği çok şey olduğunu hissediyorum ve insanlar sadece DVCS == Git düşündüklerinden ziyade benzersiz güçleri için Git'i tercih ettim.
Birisi DVCS'lerin ne kadar zeki olduğunu keşfettiğinde, belirli bir DVCS'ye işaret ederek, çoğu zaman gitmez ve başkalarına "hey, DVCS'lerin harika olduğunu, bunları kullanmalısınız", daha ziyade "DVCS = [~ # ~] i [~ # ~] DVCS'leri öğrendiğiniz harika, bunu kullanmalısınız ".
Burada üç faktör var: "beta geek media", "doğru zaman" ve "lideri takip et"
"Geeky faaliyetleri" hakkında tartışma almak kanallar vardır. Kesinlikle yeni bir sürüm kontrol sisteminin görünümünü kapsayacaklardı, ama git daha fazlasını kapsıyorlar. Neden? Çünkü Linus Torvalds başlangıçta yazdı, kamuoyunda tartıştı ve bitkeeper ile iyi duyurulmuş problemine bir çözüm olarak kullandı. Etkili bir şekilde, lkml'de bir alev savaşı olduğunda, beta geek medyası hakkında bir makale yazacaktır. Git tartışması lkml'de başladı, bu yüzden diğer alternatiflerden daha fazla kapsama aldı. Ve slashdot'u Çeşitlilik gibi okuyan beta meraklıları yedi. Bunun nihai sonucu, git'in Mercurial'dan on kat daha fazla makaleye sahip olmasıdır.
Çok sayıda katılımcı içeren büyük açık kaynak projeleri, merkezi kaynak kontrolü ile ilgili sorunlara sahiptir. Açık kaynak büyüdükçe ve projelerin birçok katılımcıya sahip olma olasılığı arttıkça sorun daha da kötüleşir. Linux muhtemelen bundan muzdarip en iyi bilinen projedir, ancak başkaları da vardır. Birçok projenin bu noktaya gelmesiyle, bir tür gelişmiş VCS'ye ihtiyaç vardı. Git, Mercurial ve Bazaar buradaki en büyük kazananlardı. Arch ve Monotone biraz erken kalmışlardı ve yutturmaca dalgasını kaçırmışlardı.
Büyük projelerin, katkıda bulunmasalar bile kodu düzenli olarak kontrol eden ve oluşturan takipçileri vardır. Takipçiler, takip ettikleri projeyi getirmek için gerekli araçlara aşina olurlar, böylece bu araçlar daha fazla faydalanır. Üç büyük DVCS için "büyük çekiliş" projelerine bir göz atalım:
Git'in daha fazla "büyük çizim" projesi var, bu yüzden git'e daha fazla kişi aşina, daha fazla git öğretici yazıyor.
Github. Github sosyal kodlamada bir öncüdür. Sürüm kontrolünü büyük ilgi gören sosyal bir platforma dönüştürdü ve sadece Git'i destekliyor. Sosyal medya = daha fazla evlat edinme. Bitbucket, çok sayıda yeni özellik kazanmasına rağmen Steam'i kazanıyor ve muhtemelen rakip oluyor :)
Aslında hype tüm DSVCs birlikte hakkında olduğunu düşünüyorum.
Ancak git savunucuları sadece daha vokaldir, dürüst olmak gerekirse ve her yerde konuşmaktan hoşlanırlar.
Mercurial'ın yaygın olarak kullanıldığından şüpheleniyorum, belki de git kadar sık, belki daha fazla (Microsoft ve diğer büyük şirketler şimdi kullanıyor), ancak Mercurial kullanan insanlar çoğunlukla bir DSVC'yi sadece bir dine dayanmak için değil, çabucak kavrayabildiklerini istediler. Bu yüzden tartışmalarda bazı git kullanıcıları gibi proaktif olmaktan daha az vokal ve daha reaktiftirler.
Çarşı kesinlikle çok fazla konuşmuyor, çünkü sadece birkaç büyük proje bunu kullanıyor ve Canonical'den başka büyük şirketler kullanmıyor. Örneğin Google (git, Mercurial, svn) ve büyük açık kaynak projeleriyle karşılaştırın ve neden gerçekten konuşulmadığını görebilirsiniz. Fosil devs bir niş için ilginç bir başka, bu yüzden sadece sağladıkları özellikleri (gömülü wiki, sorun izleme ve forum gibi) arayanlar tarafından duymak onlara normal ve iyi olduğunu düşünüyorum.
Bununla birlikte, yavaş yavaş yutturma döngüsü indirdiğimizi düşünüyorum ve birkaç farklı çözüm kullanan birçok geliştirici, birinin ihtiyaçlarına uygun olduğunu görmeye başlayabilir.
Ayrıca, Google Kod Barındırma ve SourceForge artık git ve Mercurial'a izin veriyor, böylece GitHub özellikleri nedeniyle git'i seçtiğinizde öncekinden daha projeye özgü bir seçenek haline geliyor.
Gerçek bir savaş yok, sadece ilginç bir araç çeşitliliği var.
Bu soruya çok fazla cevap olduğunu biliyorum, ama biraz daha perspektif ekleyebileceğimi hissettim.
Çarşı'yı birçok şey için yaratıldığından beri kullandım. Kullandığım en büyük şey, (şu anda) tek geliştirici ve sürdürücü olduğum AllTray projesiydi. Çarşı güzel. Sadece çalışıyor, yolumdan uzak duruyor ve neredeyse bir --help sayfasına veya bunun için man sayfasına bakmam gerekmiyor. Bununla birlikte, bunun bazı dezavantajları var:
Son zamanlarda AllTray geliştirme için git'e geçtim ve çok hızlı bir şekilde tüm projelerimi git. Halatları tanımak için biraz daha ön zaman geçirdim, ama buna değer gibi görünüyor. Fark ettiğim bazı şeyler:
git clonenispeten hızlı bir işlemdir ve klonladığınız depodaki tüm şubeler hakkında bilgi verir.
gitosissistemi de oldukça güzel. Birinin bunu Çarşı'da bir eklenti olarak nasıl uygulayacağından bile emin değilim ve bunun yakın bir yerde o kadar verimli olacağını hayal edemiyorum.
Uzun lafın kısası: bzr'i çok uzun zamandır kullandım, ama git hızla bana harikalığını kanıtlıyor.
Git'i kullandığınızda, geliştirme yaparken her zaman aynı yerel dizinde kalma eğilimindesiniz ve
git checkout branchname dalları arasında geçiş yapmak için ("hafif" özellik dalları her zaman kullanıyorum, bu yüzden bu benim için çok önemli bir özellik).
Mercurial belgelerine ve öğreticilerine bakıldığında, farklı gelişim dallarıyla başa çıkmanın tercih edilen yolunun klonlayarak yeni havuzlar oluşturmak olduğu görülmektedir. Bu eğitim bir örnektir.
Mercurial'ta git ile aynı şeyi yapabileceğinize inanıyorum, ama nedense Mercurial belgeleri (okuduğum) hemen hemen her zaman bir havuz klonu oluşturarak dallanma gösteriyor.
(Git'i günlük kullanıyorum. Mercurial ile ilgili çok az deneyimim var, onunla oynadım ve birkaç ders izledim)
Son birkaç haftada kaç tane rant gördüğümü bilmiyorum, ancak hepsi bunu Mercurial ve/veya Bazaar'ın objektif olarak Git'ten daha iyi olduğu düşünüyor. Kullanılabilirlik ortak bir tema gibi görünüyor. Evet, Git'i öğrenmek CVS ve Subversion kullandıktan sonra şaşırtıcı derecede zordu, ancak bu noktada başka bir VCS için başka bir paradigma kayması oluşturmadıkça ticaret yapmak istemem. Ve bir özellik tablosuna işaret etmek bana ne kadar esnek, genişletilebilir, güvenli veya zahmetsiz olduğunu söyleyecek. Örneğin, varsayılan olarak
git-diff Renkler ve çağrı cihazı kullanır. Elbette aynı şeyi
diff ... | colordiff | less -R Veya başka bir şeyle alabilirim, ancak birinin neden diğerinden üstün olduğu açık olmalıdır.
Adil olmak gerekirse, git ve Mercurial savunucularının git ve merkezi savunucularına kıyasla çok az olduğunu düşünüyorum. Bununla birlikte, nedenleri özetlemek kolaydır:
Git, programcılar için sürüm kontrolüdür. Mercurial, işletmeler için sürüm kontrolüdür. Centralized, özellikle kişisel bilgisayar devriminden önce tasarlandığı düşünüldüğünde, sürüm kontrolü icat etmek için yeterli bir ilk denemeydi.
Programcılar için sürüm kontrolü ile kastettiğim, programcıların genel olarak esnekliği öğrenme kolaylığı üzerinde tercih etmeleridir. Sonuçta, bilgisayarların eğitimsizlerin yapamayacağı esnekliğe sahip olabilmesi için yıllarca ezoterik dil öğrenmeye hazırız. Git, programcılara kullanma esnekliğini verir, ancak istedikleri gibi, bu esnekliğin nasıl güvenli bir şekilde kullanılacağını öğrenmek daha uzun sürer. Politikaları uygulamak için kısıtlamaların uygulanmasına izin verir, ancak kutudan çıkmaz. Not kullanım kolaylığı yerine öğrenme kolaylığı dedim. Bir kez öğrendikten sonra, git diğer VCS gibi kullanımı kadar kolaydır ve artan hız ve özellikler nedeniyle genellikle daha kolaydır.
Bazı programcılar istediklerini yapacak kadar öğrenirler, sonra bunu yapmanın yeni yollarını öğrenmeye direnirler. İşletmeler bu insanların birçoğunu işe alır ve istihdam eder, bu nedenle kullandıkları araçlarda herhangi bir değişikliğe sahip olmak ister. İşletmeler ayrıca programcılarının işlerini yapmak için yeterli esnekliğe sahip olmalarını istemektedir, ancak eğitimi veya ilk göçü zorlaştıracak kadar da değil. Burası Mercurial'ın oturduğu yerdir. Git gücünün çoğuna sahiptir, ancak biraz daha kolay bir göç yolu vardır.
Git'in sadece hype veya Linus'un onayından dolayı popüler olduğunu söylemenin adil olduğunu düşünmüyorum. Muhtemelen birçok insanı açıklıyor deniyor, ama onlar onunla sopa ve teşvik çünkü saf ve basit, onlar için iyi çalışıyor.
NetBSD geliştirme CVS kullanır ve önemli olan budur.
Zıpkınlar için iyi ödünç veren daha keskin, daha özlü bir adı var.
Son zamanlarda kişisel projeler için bir sürüm kontrol sistemi arıyordum, bu yüzden bir sürü denedim. Komut satırında neredeyse okuma yazma bilmiyorum ve GUI'ler mevcut olmasına rağmen Git'in gerçekten komut satırından kullanılmak üzere tasarlandığını duydum, bu da beni biraz tereddüt ettirdi. Dürüst olmak gerekirse, almak gülünç kolaydı ve gerçekten keyif alıyorum. Dokümantasyon, yeni bir teknolojinin benimsenmesinde büyük bir faktördür ve Git'in açık ve kullanılabilir tonlarca gülünç derecede basit dokümantasyonu vardır. SVN ve Bazaar gibi diğer alternatifler harikaydı, Git kadar kolay olmadılar. Github da şu anda büyük bir faktördür, çünkü şu anda açık kaynak hareketinin merkezinde yer almaktadır. Kod ve proje alışverişinde (ironik olarak) merkezi bir konuma sahip olmak kendi başına bir oyun değiştiricidir.
Sadece 2 ¢ - Alternatifleri tercih ettim çünkü radtool dili ya da aşırı akademik üst düzey bir dil yerine C dilinde yazılmış. Yararları, hızlı ve verimli olması ve açıklayamadığım hatalar veya davranışlarla karşılaşırsam aslında RTFS yapabilmemdir. Aynı zamanda devasa tercümanlar/çalışma zamanları içermeyen küçük, kendi kendine barındırılan geliştirme ortamlarında kullanılmasını mümkün kılar, yani doğrudan bir git deposundan çekebilir ve başka bir yerde en yeni kaynağı ve rsync'i almak yerine bu tür sistemlerde derleyebilirim.
Bahsetmemek gerekirse Apple şimdi Objective C topluluğuna itmekle ilgilendi, yakın zamanda Xcode 4'te yeni bir uygulama oluşturduysanız, bunun otomatik olarak size Git repo yapmak istiyor.
Verilen Xcode 4 sadece birkaç aydır ve Gits'in önceki başarısını etkilemiyor, ancak hepimiz ne kadar popüler olduğumuzu biliyoruz Apple kısa bir sürede şeyler yapabilir.