Ben kullanıyorum Subversion birkaç yıldır ve kullandıktan sonra SourceSafe'ı , sadece Subversion seviyorum. TortoiseSVN ile birlikte , bunun nasıl daha iyi olabileceğini hayal bile edemiyorum.
Ancak Subversion'un sorunları olduğunu ve Git gibi dağıtılmış sürüm kontrol sistemlerinin yeni türüne geçmemiz gerektiğini iddia eden artan sayıda geliştirici var .
Git Subversion'da nasıl gelişir?
Yanıtlar:
Git Subversion'dan daha iyi değil. Ama daha da kötü değil. Bu farklı.
Temel fark, merkezi olmayan olmasıdır. Yolda bir geliştirici olduğunuzu, dizüstü bilgisayarınızda geliştirdiğinizi ve 3 saat geri gidebilmeniz için kaynak kontrolüne sahip olmak istediğinizi düşünün.
Subversion ile bir Sorununuz var: SVN Deposu ulaşamayacağınız bir yerde olabilir (şirketinizde ve şu anda internetiniz yok), taahhütte bulunamazsınız. Kodunuzun bir kopyasını oluşturmak istiyorsanız, kelimenin tam anlamıyla kopyalayıp yapıştırmanız gerekir.
Git ile bu sorunu yaşamazsınız. Yerel kopyanız bir havuzdur ve bunu taahhüt edebilir ve kaynak kontrolünün tüm avantajlarından yararlanabilirsiniz. Ana veri havuzuna yeniden bağlandığınızda buna karşı taahhütte bulunabilirsiniz.
Bu başlangıçta iyi görünüyor, ancak bu yaklaşıma eklenen karmaşıklığı unutmayın.
Git, "yeni, parlak, havalı" bir şey gibi görünüyor. Bu hiç de kötü değil (Linus'un Linux Çekirdeği gelişimi için yazmasının bir nedeni var), ancak birçok insanın sadece yeni olduğu ve Linus Torvalds tarafından yazılmadığı için "Dağıtılmış Kaynak Kontrolü" trenine atladığını hissediyorum. neden / daha iyi olduğunu bilmek.
Subversion'un Sorunları var, ancak Git, Mercurial, CVS, TFS veya başka bir şey var.
Edit: Yani bu cevap şimdi bir yaşında ve hala birçok upvotes üretir, bu yüzden biraz daha açıklama ekleyeceğim düşündüm. Bunu yazdığından bu yana geçen yıl Git, özellikle GitHub gibi siteler gerçekten kalktığı için çok fazla ivme ve destek kazandı. Bugünlerde hem Git'i hem de Subversion'u kullanıyorum ve bazı kişisel bilgileri paylaşmak istiyorum.
Her şeyden önce, Git dağıtılmış çalışırken ilk başta gerçekten kafa karıştırıcı olabilir. Uzaktan kumanda nedir? ve İlk havuzu nasıl düzgün bir şekilde kurabilirim? başta SVN basit "svnadmin create" ile karşılaştırıldığında iki soru vardır, Git'in "git init" merkezi bir kurulum kurmak için "uygun" yolu gibi görünüyor - çıplak ve --shared parametreleri alabilir deposu. Bunun nedenleri var, ancak karmaşıklık katıyor. "Ödeme" komutunun belgelenmesi, değişen insanlar için çok kafa karıştırıcıdır.
Git merkezi olmadığınızda GERÇEKTEN parlar. Evde bir sunucum ve yolda bir dizüstü bilgisayarım var ve SVN burada iyi çalışmıyor. SVN ile, depoya bağlı değilsem yerel kaynak denetimine sahip olamıyorum (Evet, SVK veya repo kopyalamanın yollarını biliyorum). Git ile zaten varsayılan mod budur. Bu ekstra bir komut olsa da git git yerel olarak yürütülürken, git push origin master ana dalını "origin" adlı uzaktan kumandaya iter).
Yukarıda belirtildiği gibi: Git karmaşıklığı arttırır. İki havuz oluşturma modu, ödeme klonlama, klonlama, gönderme ve itme ... Hangi komutların yerel olarak çalıştığını ve hangilerinin "sunucu" ile çalıştığını bilmek zorundasınız (çoğu insanın hala merkezi bir "ana depo" gibi olduğunu varsayıyorum. ).
Ayrıca, takım en azından Windows'ta hala yetersizdir. Evet, bir Visual Studio AddIn var, ama yine de git bash msysgit ile kullanıyorum.
SVN'nin öğrenmesi ÇOK daha basit olması avantajı vardır: Nasıl oluşturulacağını, taahhüt edileceğini ve ödeme yapılacağını biliyorsanız ve gitmeye hazırsanız ve dallanma, güncelleme vb. üzerinde.
Git, bazı geliştiriciler her zaman ana veri havuzuna bağlı değilse ÇOK daha uygun olma avantajına sahiptir. Ayrıca, SVN'den çok daha hızlı. Ve duyduğum kadarıyla, dallanma ve birleştirme desteği çok daha iyi (yazılması gereken temel nedenler olduğu için bu beklenecek).
Bu, Git'in Açık Kaynak projeleri için mükemmel bir şekilde uygun olduğu için neden internette bu kadar çok uğraştığını da açıklıyor: Sadece Çatallayın, değişikliklerinizi kendi Çatalınıza yapın ve ardından orijinal proje yöneticisinden değişikliklerinizi çekmesini isteyin. Git ile bu işe yarar. Gerçekten, Github'da dene, sihir.
Ben de gördüm Git-SVN Köprüler: Merkezi depo bir Subversion deposudur, ancak geliştiriciler yerel olarak Git ile çalışır ve köprü daha sonra değişikliklerini SVN'ye iter.
Ancak bu uzun eklemeyle bile, temel mesajımın yanındayım: Git daha iyi veya daha kötü değil, sadece farklı. "Çevrimdışı Kaynak Kontrolü" ne ihtiyacınız varsa ve bunu öğrenmek için fazladan zaman harcamak istiyorsanız, bu harika. Ancak, kesinlikle merkezi bir Kaynak Kontrolünüz varsa ve / veya iş arkadaşlarınız ilgilenmediği için Kaynak Kontrol'ü ilk etapta tanıtmakta zorlanıyorsanız, SVN'nin basitliği ve mükemmel araçları (en azından Windows'ta) parlar.
Git ile hemen hemen her şeyi çevrimdışı yapabilirsiniz, çünkü herkesin kendi havuzu vardır.
Şube yapmak ve şubeler arasında birleşmek gerçekten çok kolay.
Bir proje için taahhüt haklarınız olmasa bile, yine de çevrimiçi olarak kendi havuzunuz olabilir ve yamalarınız için "push istekleri" yayınlayabilirsiniz. Yamalarınızı seven herkes, resmi koruyucular da dahil olmak üzere onları projelerine çekebilir.
Bir projeyi çatallamak, değiştirmek ve HEAD şubesindeki hata düzeltmelerinde birleşmeye devam etmek önemsizdir.
Git Linux çekirdek geliştiricileri için çalışıyor. Bu, gerçekten hızlı olduğu (olması gerektiği) anlamına gelir ve binlerce katılımcıya ölçeklenir. Git ayrıca daha az alan kullanır (Mozilla deposu için 30 kata kadar daha az alan).
Git çok esnek, çok TIMTOWTDI (Bunu yapmanın birden fazla yolu var). İstediğiniz iş akışını kullanabilirsiniz ve Git bunu destekleyecektir.
Son olarak Git depolarınızı barındırmak için harika bir site olan GitHub var .
Git'in sakıncaları:
Diğer cevaplar Git'in (harika) temel özelliklerini açıklamak için iyi bir iş çıkardı. Ancak Git'in daha iyi davrandığı ve hayatımı daha aklı başında tutmamıza yardımcı olacak çok az yol var. İşte küçük şeylerden bazıları:
git mvve git rm.
" Git neden X'ten daha iyi? " Git'in diğer SCM'lerin çeşitli artılarını ve eksilerini özetliyor.
Kısaca:
Bazı dezavantajları vardır:
En basit kullanımda Subversion ve Git hemen hemen aynı. Arasında çok fazla fark yok:
svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"
ve
git clone git@github.com:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push
Git'in gerçekten parladığı yer dallanmak ve diğer insanlarla çalışmaktır.
Google Tech Talk: Gitte Linus Torvalds
http://www.youtube.com/watch?v=4XpnKHJAok8
Git Wiki'nin karşılaştırma sayfası
Peki, dağıtıldı. Deneyler oldukça hızlı olduğunu gösterir (dağıtılmış doğası göz önüne alındığında, diffs ve loglar gibi işlemlerin hepsi yereldir, bu yüzden elbette bu durumda çok daha hızlıdır) ve çalışma klasörleri daha küçüktür (bu hala aklımdan geçmektedir).
Subversiyon veya başka bir istemci / sunucu revizyon kontrol sistemi üzerinde çalışırken, revizyonları kontrol ederek makinenizde çalışan kopyalar oluşturursunuz . Bu, havuzun nasıl göründüğü ile ilgili bir anlık görüntüyü temsil eder. Çalışma kopyanızı güncelleştirmelerle güncelleştirirsiniz ve deposu taahhütler aracılığıyla güncelleştirirsiniz.
Dağıtılmış bir sürüm denetimi ile bir anlık görüntünüz değil, tüm kod tabanınız olur. 3 aylık bir versiyonla fark yaratmak ister misiniz? Sorun değil, 3 aylık sürüm hala bilgisayarınızda. Bu sadece işlerin çok daha hızlı olduğu anlamına gelmez, aynı zamanda merkezi sunucunuzla bağlantınız kesilirse, alıştığınız işlemlerin çoğunu yine de yapabilirsiniz. Başka bir deyişle, yalnızca belirli bir düzeltmenin anlık görüntüsüne değil, tüm kod tabanına da sahip olursunuz.
Git'in sabit sürücünüzde bir sürü yer kaplayacağını düşünürdünüz, ancak gördüğüm birkaç kıyaslamadan aslında daha az zaman alıyor. Bana nasıl olduğunu sorma. Yani, Linus tarafından inşa edildi, sanırım dosya sistemleri hakkında bir iki şey biliyor.
DVCS hakkında sevdiğim ana noktalar şunlardır:
Nispeten büyük bir projenin ana nedeni, 3. noktanın yarattığı gelişmiş iletişimdir. Diğerleri güzel bonuslardır.
Komik olan şey: Subversion Repos'ta projeleri barındırıyorum, ancak Git Clone komutu ile bunlara erişiyorum.
Lütfen Google Code Projesi'nde Git ile Geliştir'i okuyun
Google Code Subversion'ı doğal olarak konuşmasına rağmen, geliştirme sırasında Git'i kolayca kullanabilirsiniz. "Git svn" araması bu uygulamanın yaygın olduğunu ve sizin de denemenizi öneririz.
Git'i bir Svn Deposunda kullanmak bana faydalar sağlar:
backup/public svn depom varBuradaki tüm cevaplar beklendiği gibi, programcı merkezli, ancak şirketiniz kaynak kodu dışında revizyon kontrolü kullanıyorsa ne olur? Kaynak kodu olmayan ve sürüm kontrolünden yararlanan ve başka bir CMS'de değil koda yakın yaşaması gereken birçok belge vardır. Çoğu programcı tek başına çalışmaz - şirketler için bir ekibin parçası olarak çalışırız.
Bunu göz önünde bulundurarak, Subversion ve git arasındaki hem istemci takımında hem de eğitimde kullanım kolaylığını karşılaştırın. Herhangi bir dağıtılmış revizyon kontrol sisteminin daha kolay kullanılacağı veya programcı olmayana açıklanacağı bir senaryo göremiyorum . Yanlış kanıtlanmak isterim, çünkü o zaman git'i değerlendirebilir ve aslında programcı olmayan sürüm kontrolüne ihtiyaç duyan insanlar tarafından kabul edilme umudum olur.
O zaman bile, yönetim tarafından neden merkezileştirilmiş bir revizyon kontrol sistemine geçmemiz gerektiği sorulursa, dürüst bir cevap vermek için zorlanıyorum, çünkü buna ihtiyacımız yok.
Feragatname: Subversion ile daha önce (v0.29 civarında) ilgilenmeye başladım, bu yüzden önyargılıyım, ancak o zamandan beri çalıştığım şirketler coşkumdan yararlanıyor çünkü kullanımını teşvik ettim ve destekledim. Çoğu yazılım şirketinde böyle gerçekleştiğinden şüpheleniyorum. Git bandwagonuna atlayan çok sayıda programcıyla, kaç şirketin kaynak kodunun dışında sürüm kontrolü kullanmanın faydalarını kaçıracağını merak ediyorum? Farklı ekipler için ayrı sistemleriniz olsa bile, bakım, donanım ve eğitim gereksinimlerini artırırken (birleşik) sorun izleme entegrasyonu gibi bazı avantajları kaçırıyorsunuz.
Subversion hala daha çok kullanılan bir sürüm kontrol sistemidir, bu da daha iyi araç desteğine sahip olduğu anlamına gelir. Hemen hemen her IDE için olgun SVN eklentileri bulacaksınız ve iyi explorer uzantıları var (TurtoiseSVN gibi). Bunun dışında Michael ile aynı fikirdeyim : Git Subversion'dan daha iyi ya da kötü değil, farklı.
SubVersion ile ilgili beni ilgilendiren şeylerden biri, projenin her dizinine kendi klasörünü koyması, git'in ise kök dizine yalnızca bir klasör koymasıdır. O değil o kadar önemliyse, ama böyle küçük şeyler birikir.
Tabii ki SubVersion, genellikle çok hoş olan Tortoise'a sahiptir.
David Richards WANdisco Subversion / GIT Blog'u
GIT'in ortaya çıkışı, beraberinde GIT dışında herhangi bir şeyin saçma olduğunu düşünen bir DVCS köktendincileri - 'Gitterons' cinsi getirdi. Gitterons, yazılım mühendisliğinin kendi adalarında gerçekleştiğini düşünüyor ve çoğu kuruluşun sadece kıdemli yazılım mühendislerini istihdam etmediğini unutuyor. Sorun değil ama pazarın geri kalanı böyle düşünmüyor ve bunu kanıtlamaktan mutluluk duyuyorum: GIT, son bakışta pazarın yüzde üçünden daha azına sahipken Subversion beş milyon kullanıcı bölgesinde ve yaklaşık yarısında genel pazar.
Gördüğümüz sorun Gitterons'un Subversion'da (ucuz) atış yapmasıydı. “Subversion çok yavaş / berbat / kısıtlayıcı / iyi kokmuyor / bana komik bir şekilde bakıyor] ve şimdi GIT var ve [hayatımda her şey çalışıyor / eşim hamile kaldı / sonra bir kız arkadaşım var 30 yıllık deneme / blackjack masasında altı kez koştum]. Resmi aldınız.
Git ayrıca dallanma ve birleştirmeyi de gerçekten kolaylaştırır. Subversion 1.5 yeni birleştirme takibi ekledi, ancak Git hala daha iyi. Git ile dallanma çok hızlı ve ucuzdur. Her yeni özellik için bir şube oluşturmayı daha uygun hale getirir. Oh ve Git depoları, Subversion'a kıyasla depolama alanında çok verimlidir.
Her şey bir şey yapmak için gerekli kullanım kolaylığı / adımlar ile ilgilidir.
PC / dizüstü bilgisayarımda tek bir proje geliştiriyorsam, git daha iyidir, çünkü kurulumu ve kullanımı çok daha kolaydır. Bir sunucuya ihtiyacınız yoktur ve birleştirme yaptığınızda depo URL'lerini yazmaya devam etmenize gerek yoktur.
Sadece 2 kişi olsaydı, git'in daha kolay olduğunu söyleyebilirim, çünkü sadece birbirinden itip çekebilirsiniz.
Bir kez bunun ötesine geçerseniz, yıkıma giderdim, çünkü bu noktada bir 'özel' sunucu veya konum ayarlamanız gerekir.
Bunu SVN'de olduğu gibi git ile de yapabilirsiniz, ancak git'in avantajları, merkezi bir sunucu ile senkronize etmek için ek adımlar atma gereğinden daha ağır basar. SVN'de sadece taahhütte bulunuyorsunuz. Git'e git ve git tuşuna basmalısınız. Ek adım, sinir bozucu olur çünkü bunu çok fazla yaparsınız.
SVN'nin daha iyi GUI araçları da var, ancak git ekosistemi hızlı bir şekilde yetişiyor gibi görünüyor, bu yüzden uzun vadede bunun için endişelenmeyeceğim.
Easy Git , Git ve SVN'nin gerçek kullanımını karşılaştıran güzel bir sayfaya sahiptir ve bu size Git'in SVN'ye kıyasla neler yapabileceği (veya daha kolay yapabileceği) hakkında bir fikir verecektir. (Teknik olarak, Git'in üstünde hafif bir sargı olan Kolay Git'e dayanır.)
Git ve DVCS genel olarak birbirinden bağımsız olarak çok fazla kodlama yapan geliştiriciler için mükemmeldir, çünkü herkesin kendi dalı vardır. Başka birinden bir değişikliğe ihtiyacınız varsa, yerel repoya bağlı kalması gerekir ve o zaman bu değişiklik setini size itmeli veya ondan çekmelisiniz.
Benim kendi mantığım da, merkezi yayınlar gibi şeyler yaparsanız DVCS'nin KG ve yayın yönetimi için işleri zorlaştırdığını düşündürüyor. Birisi, herkesin deposundan bu itme / çekme işleminden, daha önce ilk başlatma zamanında çözülecek olan çatışmaları çözmekten, sonra derlemeyi yapmaktan ve diğer tüm geliştiricilerin depolarını yeniden senkronize etmekten sorumlu olmalıdır.
Bütün bunlar elbette insan süreçleriyle ele alınabilir; DVCS, bazı yeni kolaylıklar sağlamak için merkezi sürüm kontrolü ile düzeltilen bir şeyi kırdı.
Git'i seviyorum çünkü aslında iletişim geliştiricisinin orta ila büyük bir ekipte geliştiriciye yardımcı oluyor. Dağıtılmış bir sürüm kontrol sistemi olarak, itme / çekme sistemi sayesinde, geliştiricilerin tek bir proje üzerinde çalışan geniş bir geliştirici havuzunu yönetmeye yardımcı olan bir kaynak kodu eko sistemi oluşturmalarına yardımcı olur.
Örneğin, 5 geliştiriciye güvendiğinizi ve yalnızca depolarından kodlar çektiğinizi varsayalım. Bu geliştiricilerin her birinin, kodları çektikleri kendi güven ağları vardır. Dolayısıyla gelişme, kod sorumluluğunun geliştirme topluluğu arasında paylaşıldığı geliştiricilerin güven dokusuna dayanmaktadır.
Tabii ki burada diğer cevaplarda bahsedilen başka faydalar da var.
Bunlara birkaç cevap verilmiş, ancak 2 noktayı açık yapmak istiyorum:
1) Seçici taahhüt yapma yeteneği (örneğin git add --patch). Çalışma dizininiz aynı mantıksal değişikliğin parçası olmayan birden çok değişiklik içeriyorsa Git, değişikliklerin yalnızca bir kısmını içeren bir taahhütte bulunmayı çok kolaylaştırır. Subversion ile zor.
2) Değişikliği kamuya açıklamaksızın taahhüt yapabilme becerisi. Subversion'da, herhangi bir taahhüt derhal halka açıktır ve bu nedenle geri alınamaz. Bu, geliştiricinin "erken taahhüt, sık taahhüt" kabiliyetini büyük ölçüde sınırlar.
Git sadece bir VCS'den daha fazlasıdır; aynı zamanda yamalar geliştirmek için bir araçtır. Subversiyon sadece bir VCS'dir.
Subversion'un iyi olduğunu düşünüyorum ... birleştirmeye başlayıncaya kadar veya karmaşık bir şey yapmaya başlayıncaya kadar ya da herhangi bir şey yapma Subversion'un karmaşık olduğunu düşünüyor (hangi dalların belirli bir dosya ile karıştığını bulmak için sorgular yapmak, bir değişikliğin gerçekte nereden geldiğini bulmak, kopya ve macunları tespit etmek gibi) , vb)...
GIT'in ana faydasının çevrimdışı çalışma olduğunu söyleyerek kazanan cevaba katılmıyorum - kesinlikle yararlı, ancak daha çok kullanım durumum için ekstra gibi. SVK da çevrimdışı çalışabilir, yine de benim için öğrenme süreme ne yatırım yapacağım sorusu yoktur).
Sadece inanılmaz derecede güçlü ve hızlı ve, kavramlara alıştıktan sonra - çok yararlı (evet, bu anlamda: kullanıcı dostu).
Birleştirme öyküsü hakkında daha fazla bilgi için şuraya bakın: svn birleştirme işlemine yardımcı olması için git-svn (veya benzeri) * just * kullanımı?
Merkezi bir sunucuyla sürekli iletişim kurması gerekmediği için, hemen hemen her komut bir saniyeden daha kısa sürede çalışır (açıkçası git push / pull / fetch daha yavaştır çünkü SSH bağlantılarını icat etmeleri gerekir). Dallanma çok daha kolaydır (dallara basit bir komut, birleştirmek için basit bir komut)
Merkezi havuzun suyunu çamurlamadan Git'teki kaynak kodumun yerel şubelerini yönetmeyi kesinlikle seviyorum. Çoğu durumda Subversion sunucusundan kod satın alır ve bunu yapabilmek için yerel bir Git deposu çalıştırırım. Git deposunu başlatmanın dosya sistemini her yerde bir grup can sıkıcı .svn klasörü ile kirletmemesi de harika.
Ve Windows araç desteği kadar, TortoiseGit temelleri çok iyi idare eder, ancak günlüğü görüntülemek istemediğimde hala komut satırını tercih ederim. Tortoise {Git | SVN} komut günlüklerini okurken yardımcı olma şeklini gerçekten çok seviyorum.
Bu sorulması gereken yanlış soru. Git'in siğillerine odaklanmak ve yıkımın en azından bazı kullanım durumları için görünüşte daha iyi olduğu hakkında bir argüman oluşturmak çok kolaydır. Git'in başlangıçta düşük seviyeli bir versiyon kontrol konstrüksiyon seti olarak tasarlanmış olması ve barok linux-geliştirici odaklı bir arayüze sahip olması, kutsal savaşların çekiş ve algılanan meşruiyet kazanmasını kolaylaştırıyor. Git taraftarları, davulları milyonlarca iş akışı avantajı ile vurur, bu da erkeklerin gereksiz olduğunu ilan eder. Çok geçmeden tüm tartışma, kurumsal svn araç topluluğunun çıkarlarına hizmet eden merkezi ve dağıtılmış olarak çerçevelenir. Genellikle yıkımın şirketteki üstünlüğü hakkında en ikna edici makaleleri ortaya koyan bu şirketler,
Ama sorun şu: Subversion mimari bir çıkmaz sokak .
Oysa svn, git'te olduğu kadar yakın bir yerde temel birleştirme izlemesi bile elde edemediğinden iki kattan fazla olmasına rağmen git ve merkezi bir yıkım değiştirme işlemi kolayca yapabilirsiniz. Bunun temel nedenlerinden biri, şubeleri dizinlerle aynı yapmak için tasarım kararıdır. Neden bu şekilde gittiğini bilmiyorum, kısmi kasaları kesinlikle çok basit hale getiriyor. Ne yazık ki, tarihi düzgün bir şekilde takip etmeyi de imkansız hale getiriyor. Şimdi belli ki şubeleri normal dizinlerden ayırmak için yıkım veri havuzu yerleşim kurallarını kullanmanız gerekiyor ve svn bazı şeyleri günlük kullanım durumlarında işler hale getirmek için bazı buluşsal yöntemler kullanıyor. Ancak tüm bunlar sadece çok zayıf ve sınırlayıcı bir alt düzey tasarım kararına dayanıyor. Havuz tabanlı fark (dizin bazında fark yerine) yapabilmek, sürüm kontrol sistemi için temel ve kritik işlevselliktir ve iç kısımları büyük ölçüde basitleştirerek daha akıllı ve kullanışlı özellikler oluşturmayı mümkün kılar. Yıkılmayı genişletmek için harcanan çaba miktarını ve birleşme çözümü gibi temel operasyonlar açısından modern VCS'lerin mevcut mahsulünden ne kadar geride olduğunu görebilirsiniz.
Şimdi, Subversion'un öngörülebilir gelecek için yeterince iyi olduğuna inanan herkes için yürek ve agnostik tavsiyem:
Subversion asla RCS ve CVS hatalarından öğrenilen daha yeni VCS ırklarına yetişmeyecektir; depo modelini sıfırdan tekrar yenilemedikçe teknik bir imkânsızlıktır, ama o zaman bu gerçekten olmaz mıydı? Modern bir VCS'nin yeteneklerini ne kadar düşünmediğinizden bağımsız olarak, cehaletiniz sizi Subversion'un tuzaklarından korumaz, bunların çoğu diğer sistemlerde imkansız veya kolayca çözülebilen durumlardır.
Bir çözümün teknik kalitesinin svn'de olduğu gibi çok net olması son derece nadirdir, kesinlikle win-vs-linux veya emacs-vs-vi hakkında böyle bir görüş bildirmeyeceğim, ancak bu durumda öyle clearcut ve kaynak kontrolü, geliştiricinin cephaneliğinde o kadar temel bir araçtır ki, açık bir şekilde ifade edilmesi gerektiğini hissediyorum. Örgütsel nedenlerle svn kullanma gereksinimi ne olursa olsun, tüm svn kullanıcılarının mantıksal zihinlerinin daha modern VCS'lerin yalnızca büyük açık kaynaklı projeler için yararlı olduğuna dair yanlış bir inanç inşa etmelerine izin vermemelerine izin veriyorum. Geliştirme çalışmanızın doğası ne olursa olsun, bir programcıysanız, Git, Mercurial, Darcs veya diğerleri gibi daha iyi tasarlanmış VCS'lerin nasıl kullanılacağını öğrenirseniz daha etkili bir programcı olacaksınız.
Subversion kullanımı çok kolaydır. Son yıllarda hiç bir sorun bulamadım ya da bir şeyin beklendiği gibi çalışmadığını gördüm. Ayrıca birçok mükemmel GUI aracı vardır ve SVN entegrasyonu desteği büyüktür.
Git ile daha esnek bir VCS elde edersiniz. Tüm değişiklikleri yaptığınız bir uzak depoya sahip SVN gibi kullanabilirsiniz. Ancak, çoğunlukla çevrimdışı olarak da kullanabilir ve değişiklikleri zaman zaman uzak depoya gönderebilirsiniz. Ancak Git daha karmaşık ve daha dik bir öğrenme eğrisine sahip. Kendimi ilk kez yanlış şubeler taahhüt ederken, dolaylı olarak şubeler oluşturduğumu veya hata hakkında daha fazla bilgi içermeyen hata mesajları ve daha iyi bilgi almak için Google ile nerede arama yapmam gerektiğini buldum. İşaretlerin değiştirilmesi ($ Id $) gibi bazı kolay şeyler işe yaramaz, ancak GIT'in kendi komut dosyalarını birleştirmek için çok esnek bir filtreleme ve kanca mekanizması vardır ve böylece ihtiyacınız olan her şeyi ve daha fazlasını alırsınız, ancak daha fazla zamana ve belgelerin okunmasına ihtiyaç duyar. ;)
Yerel deponuzla çoğunlukla çevrimdışı çalışıyorsanız, yerel makinenizde bir şey kaybedilirse yedeklemeniz olmaz. SVN ile çoğunlukla başka bir sunucudaki yedeklemenizle aynı anda olan uzak bir havuzla çalışıyorsunuz ... Git aynı şekilde çalışabilir, ancak Linus'un SVN2 gibi bir şeye sahip olmasının ana hedefi bu değildi. Linux çekirdek geliştiricileri ve dağıtılmış bir sürüm kontrol sisteminin ihtiyaçları için tasarlanmıştır.
Git SVN'den daha mı iyi? Yalnızca bazı sürüm geçmişine ve yedekleme mekanizmasına ihtiyaç duyan geliştiricilerin SVN ile iyi ve kolay bir hayatı vardır. Dallarla sık sık çalışan, aynı anda daha fazla sürümü test eden veya çoğunlukla çevrimdışı çalışan geliştiriciler Git'in özelliklerinden yararlanabilir. Hayatı kolaylaştırabilecek SVN ile bulunmayan saklanma gibi bazı kullanışlı özellikler vardır. Ancak diğer taraftan, tüm insanların tüm özelliklere ihtiyacı olmayacaktır. Bu yüzden SVN'in ölülerini göremiyorum.
Git'in daha iyi belgelere ihtiyacı vardır ve hata raporlaması daha faydalı olacaktır. Ayrıca mevcut kullanışlı GUI'ler nadiren görülür. Bu sefer Linux için yalnızca Git özelliklerini (git-cola) destekleyen 1 GUI buldum. Eclipse entegrasyonu çalışıyor ancak resmi olarak yayınlanmadı ve resmi bir güncelleme sitesi yok (sadece http://www.jgit.org/updates bagajından periyodik derlemeler içeren bazı harici güncelleme siteleri ) Bu yüzden Git'i bu gün kullanmanın en çok tercih edilen yolu komut satırıdır.
SourceGear'dan Eric Sink , dağıtılmış ve dağıtılmamış sürüm kontrol sistemleri arasındaki farklar üzerine bir dizi makale yazdı. En popüler sürüm kontrol sistemlerinin artılarını ve eksilerini karşılaştırır. Çok ilginç bir okuma.
Makaleler www.ericsink.com adlı blogunda bulunabilir :
İyi bir Git GUI'si arayan insanlar için Syntevo SmartGit iyi bir çözüm olabilir. Özel, ancak ticari olmayan kullanım için ücretsiz, Windows / Mac / Linux üzerinde çalışıyor ve hatta git-svn köprüsü kullanarak SVN'yi desteklediğini düşünüyorum.
http://subversion.wandisco.com/component/content/article/1/40.html
Bence geliştiriciler arasında SVN Vs. Git argümanı bir süredir şiddetleniyor, herkesin kendi görüşü daha iyi. Bu, 2010 ve Ötesinde Subversion Web Semineri sırasında ortaya çıkan sorularda bile gündeme getirildi.
Açık Kaynak Direktörümüz ve Subversion Corporation Başkanı Hyrum Wright, Subversion ve Git arasındaki farklar ve diğer Dağıtılmış Sürüm Kontrol Sistemleri (DVCS) hakkında konuşuyor.
Ayrıca, bir dizi Git kullanıcısının Subversion'a dönüşmesine neden olacağına inandığı Subversion'da Gelecek Kopya Kopyala Nesil (WC-NG) gibi yaklaşan değişiklikler hakkında konuşuyor.
Onun videosunu izleyin ve bu blog hakkında yorum yazarak veya forumlarımıza göndererek ne düşündüğünüzü bize bildirin. Kayıt basit ve sadece bir dakikanızı alacak!
Windows'ta Git artık oldukça iyi destekleniyor.
GitExtensions = http://code.google.com/p/gitextensions/ adresine bakın
ve daha iyi bir Windows Git deneyimi için kılavuz.
Git arazisinde son zamanlarda oturuyordum ve kişisel projeler için hoşuma gitti, ancak personelden gerekli düşünmedeki değişiklik, acil fayda olmadan, Subversion'dan henüz iş projelerini değiştiremem. Dahası, şirket içinde yürüttüğümüz en büyük proje , şimdiye kadar gördüğüm kadarıyla Git'te çok güzel ve sorunsuz çalışmayan svn: externals'e son derece bağımlı .
İlk olarak, eşzamanlı sürüm kontrolü çözülmesi kolay bir sorun gibi görünüyor. Hiç de değil. Neyse ...
SVN oldukça sezgisel değil. Git daha da kötü. [alaycı-spekülasyon] Bunun nedeni, eşzamanlı sürüm kontrolü gibi zor problemler gibi, geliştiricilerin iyi bir kullanıcı arayüzü yapmakla pek ilgilenmemeleri olabilir. [/ İğneleyici-spekülasyon]
SVN destekçileri dağıtılmış bir sürüm kontrol sistemine ihtiyaç duymadıklarını düşünüyor. Ben de öyle düşündüm. Ama şimdi Git'i sadece kullandığımıza inanıyorum. Şimdi sürüm kontrolü benim için ve sadece proje için çalışmak yerine ekip / proje için çalışıyor. Bir şubeye ihtiyacım olduğunda şubeye. Bazen sunucuda karşılık gelen bir dalı olan bir dalıdır ve bazen de yoktur. Üzerinde çalışmam gereken diğer tüm avantajlardan bahsetmiyorum bile (kısmen modern versiyon kontrol sistemi olan gizli ve saçma UI eksikliğine teşekkürler).
Subversion'un, en azından kullanılabilirliği ve daha basit iş akışı nedeniyle Git'ten (en azından üzerinde çalıştığım projeler için) daha iyi olduğunu düşünüyorum:
http://www.databasesandlife.com/why-subversion-is-better-than-git/