it-swarm.asia

Git neden bu kadar çok abartı aldı? ... diğerleri değil mi?

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?

127
dagnelies

GitHub veya Gitorious gibi hizmetlerin büyük bir faktör olduğuna inanıyorum. İnsanlar için eşyalarını bir yerde barındırabilmeleri önemlidir ve özellikle GitHub bunun için harika bir hizmettir.

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.

87
deadsven

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.

86
Thaddee Tyl

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.

77
Justin Shield

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.

34
user1249

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.

23
TheLQ

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.

14
mcottle

Bu mütevazı bir görüş, ama git iki parametre nedeniyle tüm bu yutturmaca alabilir:

  1. Çok verimli
  2. Kullanımı eğlenceli (bir çeşit bilgisayar bilimcisi tarzında)

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

13
Thibault J

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

12
jalf

Burada üç faktör var: "beta geek media", "doğru zaman" ve "lideri takip et"

Beta Geek Medya

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

Doğru zaman

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

Lideri takip edin

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: Linux, Perl, jQuery, Ruby
  • Mercurial: Java, Mozilla, Python
  • Çarşı: Ubuntu, Emacs

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.

12
Sean McMillan

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 :)

11
DelvarWorld

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.

7
Klaim

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:

  1. Çekirdek VCS'nin bir parçası olması gerektiği gibi sahip olduğu birçok işlevsellik değil. Tarihin ikiye bölünmesi, bir çağrı cihazı aracılığıyla uzun çıktıların çalıştırılması veya “kolokasyonlu” dalların (örneğin, git-tarzı depolar) olması gibi şeyler eklenti olarak sağlanır.
  2. Bir çok eklenti o kadar kararlı değil. Örneğin, koordine edilen şubelerin işlevselliği sunucu tarafında iyi çalışmıyor gibi görünüyor (en azından, hiç işe yaramadım, verilen yoldaki dalın, tam önünüzde ve kanlı şeyi görebilirsiniz).
  3. Hiçbir "klon" işlemi yoktur, dalları birer birer çekersiniz. Yeni şubeleri verimli bir şekilde çekebilmek için bir depoya sahip olmak istiyorsanız ekstra iş yapmanız gerekir.
  4. Bazı projeler için acı verici yavaştır. Bir ara “bzr branch lp: mysql” deneyin.
  5. Kancalara güçlü bir desteği yoktur; kanca sağlayan bzr eklentileri yazabilirsiniz, ancak sunucu tarafı rasgele kanca komut dosyalarına sahip olmanın standart bir yolu yoktur.

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:

  1. git clone nispeten hızlı bir işlemdir ve klonladığınız depodaki tüm şubeler hakkında bilgi verir.
  2. Ek uzak depolar eklemek ağrısızdır ve böylece birden fazla şubesi olan birçok farklı havuzu izleyebilirsiniz.
  3. Pro Git kitabı çevrimiçi olarak kullanılabilir ve e-kitap okuyucu cihazları da dahil olmak üzere birçok biçimde ve zor bir okuma değil .
  4. git, Bazaar'a göre daha kolay uzanıyor gibi görünüyor ve bunu yapmak için belirli bir API kullanmak zorunda değilsiniz. (Not: Bu hem yukarı hem de aşağı yönlüdür.)
  5. git yerleşik ikiye sahiptir ve bu özelliğin faydasını yeterince vurgulayamam.
  6. GitHub oldukça güzel.
  7. gitosis sistemi 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.

6
Michael Trausch

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)

5
codeape

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.

4
l0b0

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.

3
Karl Bielefeldt

NetBSD geliştirme CVS kullanır ve önemli olan budur.

2

Zıpkınlar için iyi ödünç veren daha keskin, daha özlü bir adı var.

2

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.

1
Morgan Herlocker

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.

Birkaç yıl önce svn'den taşınmaya karar verdiğinde neden GNOME masaüstü projesi 'nin gitmeyi hg ve bzr yerine seçtiğini okumak isteyebilirsiniz. Elbette çok ateşli dini tartışmalar vardı, ama bu GNOME Wiki sayfası bu topluluğa uyguladıkları artıları ve eksileri güzel bir şekilde özetler.

1
calum_b

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.

0
tutts