Neden Git Subversion daha iyi?

oy
393

Ben kullanıyorum Subversion'ı birkaç yıldır ve kullandıktan sonra SourceSafe'ı , sadece Subversion seviyorum. Ile birlikte TortoiseSVN , gerçekten bunu daha iyi nasıl olabilir düşünemiyorum.

Ancak bu Subversion iddia geliştiriciler artan sayıda sorunları var ve biz gibi dağıtılmış sürüm kontrol sistemleri, yeni nesil hareket edilmesi gerektiğini yoktur Git .

Nasıl Git Subversion üzerine nasıl artırır?

Oluştur 03/08/2008 saat 23:38
kaynak kullanıcı
Diğer dillerde...                            


30 cevaplar

oy
548

Git Subversion daha iyi değildir. Ama aynı zamanda değil kötüdür. Bu farklı.

temel farkı, merkezi olmayan olmasıdır. Yolda bir geliştirici hayal dizüstü bilgisayarınızda geliştirmek ve size geri 3 saat gitmek böylece kaynak kontrole sahip olmak istiyorum.

, Sen taahhüt edemez SVN Deposu sen ulaşamadığı bir konumda olabilir (Şirketinizde ve şu anda internet yok): Subversion ile, Sorun var. Kodunuzun kopyasını yapmak istiyorsanız, kelimenin tam anlamıyla kopya / yapıştırmak zorunda.

Git ile, bu sorunu yok. Yerel kopya deposudur ve bunun taahhüt ve kaynak kontrolünün tüm avantajları elde edebilirsiniz. Eğer ana deposuna bağlantısı yeniden zaman, buna karşı taahhüt edebilir.

Bu ilk bakışta iyi görünüyor, ama sadece bu yaklaşıma akılda eklenen karmaşıklığı tutun.

Git "Yeni, parlak, havalı" şey gibi görünüyor. bu yeni ve Linus Torvalds tarafından yazılan sırf aslında olmadan hiçbir (Linus sonuçta Linux Kernel gelişimi için yazdım bir neden yoktur) kötü Yoluyla, ama birçok kişi "Distributed Kaynak Denetimi" trende atlamak hissediyorum / daha iyidir, neden bilmeden.

Subversion Sorunları vardır, ama bu yüzden Git, Mercurial, CVS, TFS ya da her neyse yapar.

Düzenleme: Yani bu cevabı şimdi bir yaşında ve hala pek çok upvotes üretir, bu yüzden ben biraz daha açıklama ekleyeceğiz düşündük. Bu yazma beri geçen yıl, Git GitHub'dan gibi siteler gerçekten çıkardı özellikle beri, momentum ve çok destek kazanmıştır. Bugünlerde Git ve Subversion'ı hem kullanıyorum ve bazı kişisel fikir paylaşmak istiyorum.

Her şeyden önce, Git merkezi olmayan çalışan ilk ne zaman gerçekten kafa karıştırıcı olabilir. Uzak nedir? ve Nasıl düzgün başlangıç ​​depo kurmak için? Özellikle svn'nin basit "svnadmin oluşturmak", görünüyor seyahatseverlerin Git parametreleri --bare alabilir "git init" ve --shared merkezi kurmak için "doğru" yolu olmalı kıyasla başında gelip iki soru vardır deposu. Orada Bunun nedenleri vardır, ancak bu karmaşıklık ekler. "Çıkış" komutunun dokümantasyon üzerinde değişen insanlara çok kafa karıştırıcı - "git ödeme" dalları geçiş gibi görünüyor ederken "doğru" yolu, "git clone" gibi görünüyor.

Eğer dağıtılmış olduğunda Git GERÇEKTEN parlar. Yolda evde bir sunucu ve bir Laptop var, ve SVN basitçe burada iyi çalışmıyor. Ben deposuna bağlı değilim eğer SVN ile ben (Evet, SVK hakkında veya repo kopyalamak için yollar hakkında bilmek) yerel kaynak kontrole sahip olamaz. Git varken, bu zaten varsayılan mod bulunuyor. O (git git push kökenli usta uzaktan adında "köken" için ana dalı iter oysa yerel olarak taahhüt taahhüt) olsa fazladan bir komut.

Yukarıdaki gibi ki: Git karmaşıklığını ekler. oluştururken havuzlardan, klon vs kasada, iki mod yerel olarak çalışmalarını komutları hangi bilmek zorunda ve "server" (Ben hala merkezi bir "ana-depo" gibi çoğu insan varsayarak yaşıyorum çalışmak hangi ... itme vs taahhüt ).

Ayrıca, kalıp en az Windows üzerinde halen yetersizdir. Evet, bir Visual Studio eklenti, ama yine de msysgit ile git bash kullanarak.

SVN öğrenmek çok daha basittir avantajı vardır: oluşturmak, işlemek ve çıkış nasıl biliyorlarsa depo yok, tüm değişiklikleri ona doğru ve gitmek için hazırsınız ve dallanma gibi pikap şeyler, sonradan vb güncelleyebilir üzerinde.

Git bazı geliştiriciler her zaman ana deposuna bağlı değilseniz o FAZLA daha uygun olduğunu avantajına sahiptir. Ayrıca, SVN çok daha hızlıdır. Ve duyduğuma göre, dallanma ve (bunlar yazıldığı çekirdek nedenleri olarak, beklenebilir ki) desteği birleştirilmesi çok daha iyidir.

Git Açık Kaynak projeleri için son derece uygundur gibi, internette bu kadar vızıltı kazanır nedeni de açıklıyor: Sadece Çatal bunun kendi Çatal değişiklikleri işlemek ve sonra değişiklikleri çekmeye orijinal proje sürdürücü sor. Git ile bu sadece çalışır. Gerçekten, büyü, Github üzerinde denemek.

merkez depo Subversion repo, ama geliştiriciler yerel Git ile çalışmak ve köprü sonra SVN yaptıkları değişiklikleri iter: Ne ayrıca bkz Git-SVN Bridges vardır.

Ama bu bile uzun eklenmesiyle, yine de çekirdek mesajla stand by: Git değil iyi ya da kötü olduğunu, sadece farklı. Eğer "Çevrimdışı Kaynak Kontrolü" ihtiyacını ve bu dili öğrenme bazı ekstra zaman harcamak istekli varsa, bu harika. Ama katı merkezi Kaynak denetim sahip ve / veya sizinle birlikte çalışanlar ilgilenmiyor çünkü ilk etapta Kaynak Kontrolü tanıtmak için çaba sarf ediyor, sonra SVN parlaklık sadelik ve (en azından Windows üzerinde) mükemmel takım.

Cevap 03/08/2008 saat 23:45
kaynak kullanıcı

oy
145

herkes kendi depo çünkü Git ile, çevrimdışı pratikte her şeyi yapabilir.

dalları yapma ve dalları arasındaki birleştirme gerçekten çok kolaydır.

Eğer bir proje için hak işlemek zorunda olmasa bile, yine de çevrimiçi kendi depo varsa ve yamalar için "itme istekleri" yayınlayabilir. senin yamaları seven herkes resmi sürdürüp dahil olmak üzere kendi proje içine çekebilir.

Bu, bir proje çatal değiştirmek ve hala BAŞ daldan onarımları birleştirilmesi tutmak Önemsiz.

Git Linux çekirdek geliştiricileri için çalışıyor. İşte bu (olması gerekenden) gerçekten hızlı olduğunu ve katkıda binlerce ölçekler gelir. Git ayrıca (Mozilla deposu için 30 kat daha az alan kadar) daha az yer kullanır.

Git çok TIMTOWTDI, çok esnek (bunu yapmak için birden fazla yolu vardır). Ne istersen iş akışı kullanabilir ve Git bunu destekleyecektir.

Son olarak, orada GitHub , Git havuzlarını barındıran harika bir site.

Git getirdiği dezavantajlar:

  • Git fazla kavram ve daha komutları vardır, çünkü öğrenmek için çok daha zordur.
  • revizyonlar tahrip etme gibi sürüm numaraları yok
  • Birçok Git komutları şifreli, ve hata iletileri derece kullanıcı düşmanca
  • o (Böyle büyük olarak iyi bir GUI yoksun TortoiseSVN )
Cevap 04/08/2008 saat 01:24
kaynak kullanıcı

oy
110

Diğer cevaplar (büyük) Git temel özelliklerini açıklayan iyi bir iş yapmış. Ama aynı zamanda bu kadar çok var biraz Git daha iyi davranır ve hayatım daha aklı başında kalmasına yardımcı olur yollar. İşte küçük şeyler bazıları şunlardır:

  1. Git 'temiz' komutu vardır. SVN umutsuzca bu diskinizde ek dosyaların dökümü ne sıklıkta dikkate alınarak, bu komutu ihtiyacı var.
  2. Git 'bisect' komutu vardır. Bu iyi.
  3. SVN her klasörde .svn dizinleri (Git yalnızca oluşturur oluşturur tek .git dizini). Yazdığınız her komut ve bunu her grep, bu .svn dizinleri görmezden yazılacak gerekecektir. Ayrıca, sadece dosyaların aklı başında kopyasını almak için bütün bir komutu ( "svn ihracat") gerekir.
  4. SVN, her dosya ve klasör, farklı bir revizyon veya şube gelebilir. İlk başta, bu özgürlüğü olması güzel geliyor. Ama ne bu aslında anlamı yerel ödeme için bir milyon farklı yolu tamamen berbat edilecek olmasıdır. (Eğer bir komut yanlış girerseniz, örneğin eğer "svn switch" yarıladı başarısız veya). Ve en kötü parçasıdır: Hiç bazı dosyaların bir yerden geliyor bir durum içine almak ve birbirinden bazıları ise, "svn durumu" her şey normal olduğunu söyleyecektir. Olayların nasıl tuhaf keşfetmek için her dosya / dizin "svn info" yapmanız gerekir. "Git durumu" herşey normale olduğunu söyler, o zaman işler gerçekten normal olduğunu güvenebilirsiniz.
  5. Sen taşımak falan sildiğiniz zaman SVN söylemeliyiz. Git Sadece anlamaya olacaktır.
  6. Ignore semantik Git'te daha kolaydır. (Örneğin .pyc * gibi) bir desen yok sayarsanız bunun için göz ardı edilecektir bütün alt dizinleri. (Eğer gerçekten sadece bir dizin için bir şey yok saymak isterseniz şunları yapabilirsiniz). SVN ile, tüm alt dizinleri arasında bir desen görmezden kolay bir yolu var gibi görünüyor.
  7. dosyaları görmezden karıştığı bir başka öğe. Git başkasını etkilemeyecek olan, (/ dışlama dosya .git / bilgilerinin kullanıldığı) ayarlarını görmezden mümkün "özel" olması için yapar.
Cevap 26/09/2008 saat 01:18
kaynak kullanıcı

oy
56

" Git X daha iyi Neden " Diğer SCMS vs Git çeşitli artılarını ve eksilerini özetliyor.

Kısaca:

  • Git izler dosyalar yerine içerik
  • Dallar hafiftir ve birleştirilmesi olduğunu kolay ve demek gerçekten kolay .
  • Temelde her depo dalıdır, dağıtılan. Benim görüşüme göre, Subversion ile daha eş zamanlı ve işbirliği içinde geliştirmek çok daha kolaydır. Ayrıca yapar çevrimdışı geliştirmeyi mümkün.
  • Bu herhangi bir iş akışını empoze etmez görüldüğü gibi, yukarıda bağlantılı web , Git ile olası birçok iş akışları vardır. Bir Subversion tarzı iş akışı kolayca taklit edilir.
  • Git depoları çok olan dosya boyutu daha küçük Subversion depoları daha. Sadece bir ".git" dizin ".svn" Depolarda onlarca aksine (Subversion 1.7 not ve daha yüksek var, artık tek bir dizin kullanır Git gibi.)
  • Evreleme alanı o sen taahhüt edecektir değişiklikleri görmek kısmi değişiklikleri kaydetmek ve diğer çeşitli şeyler yapmak için izin verir, müthiş.
  • Stashing siz "kaotik" geliştirme yapmak, ya da sadece hala (farklı dalda) başka bir şey üzerinde çalışırken bir hatayı düzeltmek istediğinizde ölçülemez.
  • Sen edebilirsiniz Tarihi yeniden hatalarınızı yama setleri hazırlanması ve sabitleme için harika, ( önce sen kaydedilmesini yayımlamak)
  • ... ve bir sürü daha.

Bazı dezavantajları vardır:

  • Bunun için birçok iyi GUI henüz bulunmamaktadır. Daha çok yeni ve Subversion çok daha uzun civarında olmuştur, bu yüzden gelişiminde birkaç arayüzleri olduğu gibi bu doğaldır. Bazı iyi olanlar şunlardır TortoiseGit ve Mac için GitHub .
  • havuzlarınızın Kısmi kasaların / klonlar şu anda mümkün değildir (Ben gelişiminde olduğunu okuyun). Ancak, alt modül desteği vardır. Git 1.7+ seyrek checkouts destekler .
  • Ben durumda (yaklaşık bir yıl önce) olmak bulamadık rağmen öğrenmesi zor olabilir. Git geçtiğimiz günlerde arayüzünü geliştirilmiş ve oldukça kullanıcı dostu olan.

En basit kullanım içinde, Subversion ve Git hemen hemen aynıdır. arasında pek bir fark yoktur:

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

Nerede Git şaşırmaya dallanma ve diğer insanlarla birlikte çalışmaktadır.

Cevap 10/02/2009 saat 05:18
kaynak kullanıcı

oy
54

Google Tech Talk: git üzerine Linus Torvalds

http://www.youtube.com/watch?v=4XpnKHJAok8

Git Wiki karşılaştırma sayfası

http://git.or.cz/gitwiki/GitSvnComparsion

Cevap 03/08/2008 saat 23:44
kaynak kullanıcı

oy
26

Eh, dağıtılan. Deneyler da oldukça hızlıdır olduğunu belirtmek (fark dosyaları ve günlükleri gibi operasyonlar tüm tabii bu durumda blazingly daha hızlı yüzden yerel, onun dağıtılmış doğası göz önüne alındığında) ve çalışma klasörler (hala fikrimi darbeler olan) daha küçüktür.

Eğer yıkılma veya başka bir istemci / sunucu revizyon kontrol sistemi üzerinde çalışırken, aslında sitelerinin makinenize kopyalarını çalışma oluşturmak kontrol dışı revizyonlar. Bu depo neye benzediğini zaman içinde anlık temsil eder. Güncellemeler aracılığıyla çalışma kopyası güncelleme ve kaydedilmesini aracılığıyla depoyu güncellemek.

dağıtılmış sürüm kontrolü ile, bir anlık değil, bütün kod tabanına sahip değildir. Ister 3 aylık bir sürümü ile yapılmış bir fark mı? Sorun değil, 3 aylık sürümü bilgisayarınızda hala. Bu tek şey yolu hızlıdır, ancak merkezi sunucudan bağlantısız konum bile, yine alıştığınız operasyonların birçok yapabiliriz anlamına gelmez. Başka bir deyişle, sadece belirli bir revizyon anlık, ancak tüm kod temeli yok.

Sen Git sabitdisk alanı bir demet kadar alacağını düşünmek istiyorum, ama gördüğüm birkaç mukayeselerden, aslında az sürer. Nasıl olduğunu sorma. Ben Linus tarafından yaptırılmıştır baksana, o sanırım dosya sistemleri hakkında bir iki şey biliyor.

Cevap 03/08/2008 saat 23:47
kaynak kullanıcı

oy
22

Ben DVCS hakkında gibi ana noktaları olanlardır:

  1. Sen kırık şeyleri tahsis edebilirler. Yayınladığınız kadar diğer halklar onları görmezsiniz çünkü önemli değildir. zamanını farklı taahhüt süreyi yayınlayın.
  2. Bu nedenle daha sık tahsis edebilirler.
  3. Sen tam functionnality birleştirebilirsiniz. Bu functionnality kendi şube sahip olacaktır. Bu şubenin tüm kaydedilmesini bu functionnality ile ilgili olacaktır. Sen DVCS ile ancak bir SVK ile varsayılan yapabilirsiniz.
  4. Eğer geçmişi (bir işlev değişti bulmak) arama yapabilirsiniz
  5. Birisi ana depo mahvedersem Bir çekme geri alabilirsiniz, hataları düzeltmek gerekmez. Sadece birleştirme temizleyin.
  6. Eğer herhangi bir dizinde bir kaynak denetimi gerektiğinde yapmak: git init. ve vb değişiklikleri geri, işleyebilir ...
  7. O (hatta Windows üzerinde) hızlı

Nispeten büyük proje için temel nedeni 3. Diğerleri güzel ikramiye olan nokta yarattığı gelişmiş iletişimdir.

Cevap 04/09/2008 saat 12:06
kaynak kullanıcı

oy
15

Garip olan: Subversion'ın Repos projeleri ev sahipliği ama Git Clone komutu kullanarak erişin.

Lütfen okuyun Google Code Projesi Git ile geliştirin

Google Code doğal Subversion'ı konuşur da, geliştirme sırasında kolayca Git kullanabilirsiniz. "Git svn" aranıyor bu uygulama yaygındır önerir ve biz de onunla denemenizi öneririz.

Bir SVN deposu üzerinde Git kullanmak bana çok yararı vardır:

  1. Ben çalışabilirsiniz dağıtılan İşleyen, ve gelen ve bunlara çekerek, birçok makineye
  2. Bir var merkez backup/public diğerleri kontrol etmek için svn deposu
  3. Ve kendi için Git kullanmakta serbesttirler
Cevap 02/10/2008 saat 14:05
kaynak kullanıcı

oy
11

Tüm cevaplar burada beklendiği gibi şirket kaynak kodunun dışında revizyon kontrolü kullanıyorsa, programcı merkezli Ancak ne olur nelerdir? Orada sürüm kontrolü yarar kaynak kodu olmayan belgelerin bol ve yakın koduna değil, başka CMS yaşamalıdır. Çoğu programcı izolasyon çalışmıyor - bir ekibin parçası olarak şirketler için çalışıyoruz.

Bunu göz önünde bulundurarak, Subversion ve Git arasında, istemci kalıp ve eğitim hem de kullanım kolaylığı karşılaştırın. Ben bir senaryo göremiyorum herhangi dağıtılmış revizyon kontrol sistemi olmayan bir programcı için kullanabilir veya açıklamak kolay olacak. Sonra budala değerlendirmek mümkün olurdu ve aslında bunun bir umut programcılar değildir sürüm kontrolüne ihtiyacımız insanlar tarafından kabul edildikten var çünkü yanlış kanıtlanmış isteriz.

Yönetim tarafından istenirse O zaman bile, neden dağıtılmış revizyon kontrol sistemine merkezi hareket etmelidir biz buna ihtiyacı yoktur, çünkü ben sert, dürüst bir cevap vermek için baskı olurdu.

Yasal Uyarı: (v0.29 civarında) erken Subversion ilgilenmeye başladı yüzden açıkçası önyargılı değilim, ama teşvik ve kullanımını desteklenen ettik çünkü o zamandan beri benim coşku faydalanmaktadır için çalıştık şirketler. Ben çoğu yazılım şirketleri ile olur bu nasıl şüpheli. Pek çok programcı git çoğunluğa atlama, ben kaynak kodunun dışında sürüm denetimi kullanmanın yararları üzerine atlamak için gidiyoruz kaç şirket acaba? Farklı ekipler için ayrı sistemlerine sahip olsa bile, bakım, donanım ve eğitim ihtiyaçlarını artan ederken, bu tür (birleşik) sorun izleme entegrasyonu gibi faydaları, bazı kaçırıyorsunuz demektir.

Cevap 13/10/2009 saat 08:01
kaynak kullanıcı

oy
9

Subversion hala daha iyi bir araç desteğine sahip olduğu anlamına gelir çok daha kullanılan sürüm kontrol sistemidir. Neredeyse her olgun SVN eklentileri bulacaksınız IDE ve (TurtoiseSVN gibi) mevcuttur iyi kaşif uzantıları vardır. Bunun dışında, benim de katıldığım gerekecek Michael : Git Subversion daha iyi ya da kötü, durum farklı.

Cevap 18/09/2008 saat 19:44
kaynak kullanıcı

oy
8

Subversion / GIT David Richards WANdisco blog

'Gitterons' - - bok GIT başka bir şey olduğunu düşünüyorum GIT ortaya çıkması bununla DVCS köktendinciler bir ırkı getirdi. Gitterons yazılım mühendisliği kendi adada olur ve genellikle en kuruluşları münhasıran kıdemli yazılım mühendisi yoktur unutma düşünüyor. Bu Tamam ama pazarın geri kalanı nasıl düşündüğünü o değil, ve bunu kanıtlamak için mutluyum Subversion'ın beş milyon kullanıcı bölge ve yaklaşık yarısında sahipken GYTE, son bakışta üçten az pazarın yüzde vardı genel piyasa.

Gördüğümüz sorun Gitterons Subversion de (ucuz) ateşleri olmasıydı. Subversion böyledir”gibi Tweetler [yavaş / boktan / kısıtlayıcı / iyi kokmuyor / komik bir şekilde bana bakıyor] ve şimdi GYTE ve [her şeyi hayatımda çalışır / eşim hamile / I got bir kız arkadaşı sonra var çalışmakla 30 yıl / I] blackjack masasında çalışan altı kez kazandı. Resmi olsun.

Cevap 17/09/2010 saat 19:22
kaynak kullanıcı

oy
8

Beni rahatsız ediyor Subversion hakkında şeylerden biri git yalnızca kök dizininde bir koyar oysa o, bir projenin her dizinde kendi klasörü koyar olmasıdır. O değil o kadar önemliyse, ama böyle küçük şeyler birikir.

Tabii ki, SubVersion [genellikle] çok güzel Kaplumbağa vardır.

Cevap 22/08/2008 saat 16:24
kaynak kullanıcı

oy
7

Git ayrıca dallanma ve gerçekten kolay birleştirme yapar. Subversion 1.5 sadece birleştirme izleme eklendi, ancak Git hala iyidir. Git dallanma ile çok hızlı ve ucuz. Daha uygun her yeni özellik için bir şube oluşturarak yapar. Subversion ile karşılaştırıldığında Oh ve Git depoları depolama alanı ile çok verimlidir.

Cevap 09/08/2008 saat 04:22
kaynak kullanıcı

oy
6

Kolay Git fiili kullanımını karşılaştıran güzel bir sayfası vardır Git ve SVN SVN ile karşılaştırıldığında size şeyler Git neler yapabileceğini hakkında bir fikir vermek (ya da daha kolay yapmak) olacaktır. (Teknik olarak, bu Git üstünde hafif sarıcı Kolay Git dayanmaktadır.)

Cevap 22/08/2008 saat 16:19
kaynak kullanıcı

oy
6

Her şey yapmak için gerekli kullanım / adımların kolaylığı ilgili.

Benim PC / dizüstü tek bir proje geliştiriyorum Eğer kurmak ve kullanımı çok daha kolay olduğu için, git, daha iyidir. Bir sunucu gerekmez ve size birleştirmeyi yaparken depo URL in yazarak tutmak gerekmez.

sadece 2 kişi vardı, ben sadece itmek ve birbirinden çekin çünkü git, ayrıca daha kolay olduğunu söyleyebilirim.

Gerçi bunun ötesinde aldıktan sonra bu noktada bir 'özel' sunucu veya konumunu ayarlamak gerekir, çünkü ben, tahrip için gider.

Sen SVN ile bu sadece yanı ile budala yapabiliriz, ama Git faydaları merkezi sunucu ile senkronize için ek adımlar yapmaya ihtiyaç tarafından galip olsun. SVN'de sadece taahhüt. GIT'de sonra işlemeye git'e zorunda itmek git'e. eğer bu kadar yapıyor sonunda çünkü ek adım can sıkıcı olur.

SVN da ancak git ekosistem hızla yetişmeye gibi görünüyor, daha iyi GUI araçları yararı vardır, bu yüzden uzun vadede bu konuda endişe olmaz.

Cevap 04/08/2008 saat 00:38
kaynak kullanıcı

oy
5

aslında büyük ekibine bir ortamda geliştirici iletişim geliştirici yardımcı çünkü Git gibi. dağıtılmış sürüm kontrol sistemi olarak kendi itme / çekme sistemi aracılığıyla, tek proje üzerinde çalışan geliştiriciler büyük bir havuz yönetmek için yardımcı olan bir kaynak kod eko-sistemi oluşturmak için geliştiriciler yardımcı olur.

Örneğin 5 geliştiriciler güven ve sadece kendi deposundan kodlarını çekin söylüyorlar. bu geliştiriciler Her onlar kodları çekin yerden kendi güven ağına sahiptir. Böylece gelişme kodu sorumluluk geliştirme topluluğu arasında paylaşılan geliştiricilerin bu güven kumaş dayanmaktadır.

Tabii burada diğer cevaplar belirtilecek diğer faydaları vardır.

Cevap 05/10/2008 saat 17:52
kaynak kullanıcı

oy
5

Genel olarak Git ve DVCS herkesin kendi şube olduğundan birbirinden bağımsız kodlama bir sürü yapıyor geliştiriciler için mükemmeldir. Eğer başkasından bir değişiklik gerekiyorsa, yine de, onun yerel repo taahhüt zorundadır ve sonra o sana o changeset itmek gerekir, aksi takdirde ondan çekin gerekir.

Kendi muhakeme ayrıca merkezi bültenleri gibi şeyler varsa bana DVCS QA için zor şeyler yapar düşünmek ve sürüm yönetimi yapar. Birisi çok baskı yapıyor sorumlu olmak zorundadır / ardından yapı yapıyor ve ardından tüm diğer geliştiricilere yeniden senkronize onların repo sahip öncesinde zaman taahhüt başlangıç ​​olarak çözümlenmiş olurdu çelişkileri çözmeye, herkesin deposundan çekin.

Bütün bunlar tabii insan süreçler ile ele alınabilir; DVCS sadece bazı yeni kolaylıklar sağlamak amacıyla merkezi versiyon kontrolü ile sabitlendi şey kırdı.

Cevap 04/08/2008 saat 00:08
kaynak kullanıcı

oy
4

Ben .. veya karmaşık bir şey yapıyor .. ya Subversion'ın bir değişiklik belirli bir dosya ile haberci hangi şube öğrenmek için sorgular yapıyor gibi (karmaşık düşünen şey yapıyor .. Eğer birleştirme başlayana kadar Subversion iyi olduğunu düşünüyorum aslında tespit kopya & macunlar, gelir , vb)...

Ben söyleyerek kazanan cevap katılmıyorum ana parası kesinlikle yararlıdır, ama benim kullanım durumu için ekstra gibi daha var - GYTE çevrimdışı eseridir. SVK hala biri benim öğrenme zamanı olarak) yatırım yapmak benim için söz konusu değildir, çok çevrimdışı çalışabilir.

Buna kavramların alışmak sonra-, inanılmaz derecede güçlü ve hızlı ve bu sadece - çok yararlı (Bu anlamda, evet: kullanıcı dostu).

Bir birleştirme hikaye hakkında ayrıntılı bilgi için, bu bkz: git-svn (veya benzeri) * sadece * svn birleştirme ile yardım etmeye kullanarak?

Cevap 27/07/2010 saat 16:40
kaynak kullanıcı

oy
4

Birkaç cevaplar bu ima, ama 2 puan açık olmak için adres:

1) yeteneği (örneğin, selektif hareketin yapmak git add --patch). Sizin çalışma dizini aynı mantıksal değişimin bir parçası olmayan çoklu değişiklikler varsa Git çok kolay bir o değişikliklerin yalnızca bir kısmını kapsamaktadır işlemek yapmak mümkün kılar. Subversion ile, zordur.

2) yeteneği değişikliği herkese açmadan işlemeye. Subversion'da, herhangi taahhüt hemen kamu ve dolayısıyla geri alınamaz. Bu büyük ölçüde "erken taahhüt sıklıkla yükleme" için geliştirici yeteneğini sınırlar.

Git bir VCS daha fazlasıdır; o da yamalar geliştirmek için bir araçtır. Subversion sadece bir VCS olduğunu.

Cevap 07/08/2009 saat 15:59
kaynak kullanıcı

oy
3

Bu yanlış bir soru sorarak edilecektir. Bu seyahatseverlerin Git en siğiller odaklanmak ve alt sürüm en azından bazı kullanım durumları için, görünüşte neden daha iyi olduğunu hakkında tartışma formüle etmek hiç de kolay. git başlangıçta düşük seviyeli sürüm kontrol inşaat seti olarak tasarlanan ve bir barok linux-geliştirici odaklı bir arayüze sahip olması gerçeği kutsal savaşlar çekiş ve algılanan meşruiyet kazanmak için daha kolay hale getirir. Git savunucuları adamlar gereksiz ilan svn iş akışı avantajları, milyonlarca davul patlama. Çok yakında bütün tartışmalar kurumsal svn aracı topluluğunun çıkarlarına hizmet, hangi dağıtılan vs merkezi etrafında döner. tipik işletmedeki Subversion'ın üstünlüğüne hakkında en inandırıcı makaleler söndürmek Bu şirketler,

Ama burada sorun şu: Subversion'ın bir mimari çıkmaz .

Eğer budala alıp etrafta olmasına rağmen oldukça kolay merkezi bir yıkılma değiştirme inşa edebilirsiniz Oysa uzun svn yanı o Git olduğu gibi yakın yerde çalışan hatta temel birleştirme-izleme almanız mümkün olmamıştı daha iki kat. Bunun temel nedenlerinden birisi dizinleri gibi dalları aynı hale getirmek için dizayn karardır. başlangıçta bu şekilde neden gittiğini bilmiyorum, kesinlikle kısmi kasaların çok basit hale getirir. Maalesef o da imkansız düzgün tarihini izlemek için kolaylaştırır. Şimdi belli ki düzenli dizinleri dalları ayırmak için yıkılma depo düzeni kuralları kullanmak gerekiyordu ve svn şeyler günlük kullanım durumları için çalışmasını sağlamak için bazı sezgisel tarama kullanan edilir. Ama bütün bu sadece çok kötü ve sınırlayıcı düşük seviyeli tasarım kararı üzerine papering edilir. Bir bir depo-bilge diff yapabilir (daha doğrusu dizin bilge fark hariç) olmak bir sürüm kontrol sistemi için temel ve kritik çalışmasıyla ilgilidir ve büyük ölçüde mümkün bunun üstüne daha akıllı ve kullanışlı özellikler yaratılmasına olanak iç görün kolaylaştırır. Sen uzanan tahrip girmiştir çaba miktarda görebilirsiniz ve henüz ne kadar gerisinde o birleştirme kararı gibi temel operasyonları açısından çağdaş VCSes mevcut ürün değil.

Şimdi burada yine Subversion öngörülebilir gelecek için yeterince iyi inanmaktadır kalbim-keçe ve herkes için agnostik tavsiye:

Subversion RCS ve CVS hatalarından öğrendim VCSes yeni ırklar yetişmek asla; bunların sıfırdan depo modelini yeniden teçhiz sürece teknik bir imkansızlık, ama o zaman gerçekten olurdu svn olmaz? Ne olursa olsun size modern bir VCS yetenekleri cehaletiniz imkansız veya kolayca diğer sistemlere çözülmesi durumlardır birçoğu Subversion'ın tuzaklar, sizi korumaz değil mi ne kadar.

Bir çözümün teknik aşağılık so-net kesilmiş o svn ile olduğu gibi olması son derece nadirdir, kesinlikle kazan-linux-vs veya emacs-vs-vi hakkında böyle görüşünü bildiren asla ama bu durumda öyle mi clearcut ve kaynak kontrol ben tümden belirtilmelidir hissediyorum, geliştiricinin cephanelik böyle temel bir araçtır. Ne olursa olsun ihtiyacının onların mantıksal akıl daha modern VCSes büyük açık kaynak projeleri için sadece yararlıdır yanlış inancı inşa izin vermemeye tüm svn kullanıcıları yalvarıyorum, örgütsel nedenlerle svn kullanmak. Eğer bir programcı iseniz bunu Git, Mercurial, Darcs veya diğerleri olsun, daha iyi tasarlanmış VCSes kullanmayı öğrenmek olursa olsun geliştirme çalışmalarının doğası, daha etkili bir programcı olacaktır.

Cevap 29/05/2011 saat 18:30
kaynak kullanıcı

oy
3

Kesinlikle merkezi depolamanın suyu muddying Git benim kaynak kodunun yerel şubesi yönetebilmek gibi seviyorum. Birçok durumda Subversion'ın sunucudan çıkış kodu ve sadece bu yapabilmek için yerel Git depo kaçıyorum. Bir Git depo başlatılıyor her yerde can sıkıcı .svn klasörler bir grup ile dosya sistemi kirletmez etmediğini de harika.

Ve bildiğim kadarıyla, Windows aracı destek olarak, TortoiseGit çok iyi temellerini kolları, ama günlüğünü görüntülemek istemedikçe ben hala komut satırını tercih ederim. Gerçekten şekilde Kaplumbağa gibi | günlükleri işlemek okurken {Git SVN} yardımcı olur.

Cevap 10/02/2010 saat 23:54
kaynak kullanıcı

oy
3

Bir saniyeden daha kısa hemen hemen her komutu çalıştırır, sürekli bir merkezi sunucu ile iletişim gerekmez aslında sayesinde (bunlar SSH bağlantıları initalise zorunda çünkü / çekme / besbelli git push getirme yavaş sade). Dallanma çok çok daha kolaydır (dalına basit bir komut, basit bir komut birleştirme)

Cevap 30/08/2008 saat 13:01
kaynak kullanıcı

oy
2

İyi Git GUI arayan insanlar için SyntEvo SmartGit iyi bir çözüm olabilir. Onun tescilli fakat ticari olmayan kullanım için ücretsiz, Windows / Mac / Linux üzerinde çalışan ve hatta SVN bence git-svn köprü çeşit kullanarak destekler.

Cevap 09/03/2011 saat 15:05
kaynak kullanıcı

oy
2

Eric Lavabo SourceGear gelen dağıtılan ve nondistributed versiyon kontrolleri sistemleri arasındaki farklar hakkında makale yazdı. O en popüler sürüm kontrol sistemlerinin avantajlarını ve dezavantajlarını karşılaştırır. Çok ilginç bir okuma.
Makaleler blogunda, bulunabilir www.ericsink.com :

Cevap 13/10/2009 saat 14:36
kaynak kullanıcı

oy
2

Subversion kullanımı çok kolaydır. Geçen yıllarda bir sorun bulmadım ya beklendiği gibi bir şeyin çalışmıyor. Ayrıca orada birçok mükemmel GUI araçlardır ve SVN entegrasyonu için destek büyük.

Git ile daha esnek bir VCS olsun. Eğer tüm değişiklikleri işlemek uzak bir depo ile bunu SVN gibi aynı şekilde kullanabilirsiniz. Ama aynı zamanda çoğunlukla çevrimdışı kullanmak ve yalnızca uzaktan deposuna zaman zaman değişiklikler zorlayabilir. Ama Git daha karmaşık ve daha dik bir öğrenme eğrisi vardır. Dolaylı olarak dalları oluşturarak veya yanlışlıkla ve nerede daha iyi bilgi almak için Google ile arama gerekir hakkında pek bilgiler ile hata iletileri almak, yanlış dallarına işlemekle ilk kez buldum. ($ Kimliği $) belirteçlerin ikamesi gibi bazı kolay şeyler çalışmıyor ama GIT kendi komut dosyalarını birleştirmek için çok esnek bir filtreleme ve kanca mekanizması vardır ve bu yüzden her şeyi almak ihtiyacınız ve daha ama daha fazla zaman ve belgelerin okunmasını ihtiyacı ;)

Yerel depo ile çoğunlukla çevrimdışı çalışıyorsanız şey yerel makinenizde kaybolması durumunda hiçbir yedek var. SVN ile çoğunlukla da başka bir sunucuda yedekleme aynı zaman uzak bir depo ile çalışıyoruz ... Git aynı şekilde çalışabilir ancak bu SVN2 gibi bir şey olması Linus ana hedefi değildi. Linux çekirdeği geliştiricileri ve dağıtılmış sürüm kontrol sisteminin ihtiyaçları için tasarlanmıştır.

Git SVN daha sonra mı? sadece bazı sürüm geçmişi ve bir yedek mekanizma ihtiyacı Geliştiriciler SVN ile iyi ve kolay bir hayat var. Geliştiriciler, şubesi bulunan çoğu zaman çalışan aynı anda birden sürümlerini test veya Git özelliklerinden yararlanabilir çoğunlukla çevrimdışı çalışma. hayatı kolaylaştırmak hangi SVN ile bulunmayan stashing gibi bazı çok yararlı özellik vardır. Ama diğer tarafta değil tüm insanlar tüm özellikleri gerekir. Yani SVN ölü göremez.

Git biraz daha iyi belgelere ihtiyacı ve hata raporlama daha yararlı olmalıdır. Ayrıca mevcut kullanışlı GUI nadiren bulunmaktadır. Ben bu kez sadece en Git özellikleri (git-cola) desteğiyle Linux için 1 GUI bulundu. Eclipse entegrasyon çalışıyor fakat resmi olmayan yayımlanan ve resmi güncelleme sitesi (sadece bazı harici güncelleme periyodik site gövdesinden inşa yoktur http://www.jgit.org/updates ) Yani bu gün Git kullanmak en çok tercih edilen şekilde komut çizgidir.

Cevap 13/10/2009 saat 14:14
kaynak kullanıcı

oy
1

Subversion'ın Git daha iyi olduğunu düşünüyorum neden esas olarak kullanılabilirliği sayesinde, ve daha basit iş akışı (ı üzerinde çalışmak projeler için en az):

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Cevap 22/10/2010 saat 17:25
kaynak kullanıcı

oy
1

Son zamanlarda Git topraklarda yaşayan edilmiştir ve ben kişisel projeler için öyle, ama ben acil faydaları olmadan, personelinden gerekli düşünce değişikliği verilmiş arşivdekini henüz kendisine iş projelerini geçiş mümkün olmaz. Üstelik biz in-house çalıştırmak en büyük proje üzerinde son derece bağlıdır dış varlıklara: svn şimdiye kadar gördüğüm kadarıyla, Git o kadar güzel ve sorunsuz bir şekilde çalışmaz.

Cevap 25/04/2010 saat 22:35
kaynak kullanıcı

oy
1

http://subversion.wandisco.com/component/content/article/1/40.html

Ben geliştiriciler arasında olduğunu söylemek oldukça güvenli olduğunu düşünüyorum, SVN Vs. Git argüman herkes hangi iyidir kendi görünüme sahip bir süredir Şiddetli olmuştur. Bu hatta 2010 ve Ötesi Subversion'dan bizim Web Seminerinin sırasında sorulardan kadar getirildi.

Hyrum Wright, Subversion Corporation için Açık Kaynak ve Cumhurbaşkanının bizim Direktörü diğer Dağıtılmış Sürüm Kontrol Sistemleri (DVCS) ile birlikte, Subversion ve Git arasındaki farklar bahsediyor.

O da böyle o geri Subversion dönüştürmek için Git kullanıcılarının bir dizi neden olacaktır inanmaktadır Çalışma Kopya Next Generation (WC-NG) gibi Subversion yakında yapılacak değişiklikler bahsediyor.

Onun videonun bir saat var ve bize bu blog üzerinde yorum ya tarafından veya forumlarımızda yayınlayarak düşündüğünüzü bildirin. Kayıt basittir, sadece birkaç saniyenizi alacak!

Cevap 10/02/2010 saat 19:51
kaynak kullanıcı

oy
1

Windows Git oldukça iyi şimdi destekleniyor.

Check out GitExtensions = http://code.google.com/p/gitextensions/

ve daha iyi bir, Windows Git deneyimi için manuel.

Cevap 10/02/2010 saat 17:29
kaynak kullanıcı

oy
1

kolay bir sorun çözmek için böyle Birincisi, eşzamanlı sürüm kontrolü gibi görünüyor. Hiç de değil. Neyse ...

SVN oldukça olmayan sezgisel. Git daha da kötü. [Alaycı-spekülasyon] geliştiriciler, eşzamanlı sürüm kontrolü gibi sert problemler gibi, iyi bir UI yapımında pek ilgi yok olmasından kaynaklanabilir. [/ Iğneleyici-spekülasyon]

SVN taraftarlar dağıtılmış sürüm-kontrol sistemini gerekmez düşünüyorum. Ben de düşündüm. Ama şimdi sadece Git kullandığını, ben inanırım. Şimdi sürüm kontrolü bana VE yerine proje için çalışma ekibi / proje için çalışıyor. Ben bir şube ihtiyacım olduğunda, dallanır. Bazen sunucuda karşılık gelen şubesi vardır bir kolu ve bazen değil. Değil ben (modern bir versiyonu kontrol sistemidir UI gizli ve saçma olmaması nedeniyle kısmen sayesinde) üzerinde çalışma gitmek gerekecek diğer tüm avantajlarını söz.

Cevap 03/01/2010 saat 13:45
kaynak kullanıcı

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more