Ben de dahil daha önce kimsenin kaynak kontrolünü kullanmadığı bir bölümde çalışıyorum.

Kavramı zorlamaya çalışıyorum. SVN'yi araştırırken biraz zaman geçirdim. Bazı temel bilgileri öğrendim. Komut satırıyla ve Kaplumbağa ile oluşturabilir / güncelleyebilir / satın alabilir / taahhüt edebilirim. Nasıl etiketleneceğini ve dallanacağını öğrenmeye başlıyorum, ancak dallar ve gövde vb. Arasındaki çatışmalar konusunda hala kafam karıştı. Hepsi kitaplardan / derslerden ve deneme yanılmadır.

Çevrimiçi okuduklarımdan git, bilmek daha iyi bir şey gibi görünüyor , ama aynı zamanda daha da karmaşık. Kendimi boğmak istemiyorum. Git'e gitmeden önce svn'de ustalaşmaya devam etmeli miyim yoksa şimdi gitmeye atlamak daha akıllıca mı olurum?

Her iki yaklaşımın da artıları ve eksileri var mı?

Yok hayır

Git SVN'den radikal bir şekilde farklı, size yardımcı olmayacak. Herhangi bir şey "güncelleme" ve "taahhüt" komutlarını arayacak ve her şeyin neden farklı olduğunu merak edeceksiniz.

Git ile Bottom Up'dan başlayın ve oradan gidin.

Standart bir merkezi güncelleme / işleme modeli sürüm sisteminin Git ile karşılaştırılması, bir veri yolunu toplu taşıma ile karşılaştırmaya benzer. Bir otobüs, sizi (ve diğer herkesi) aynı güzergahı kullanarak A noktasından B noktasına getirecektir. Toplu taşıma, istediğiniz rotayı kullanarak sizi A noktasından B noktasına götürür.

Dağıtılmışın bilmeniz gereken dezavantajları vardır. Herkesi aynı sayfada tutmak daha fazla iş gerektiriyor. Yine de esneklikte büyük bir artış sunuyor.

Revizyon karmaları vs. Sayılar

Hg sayıları kullanırken biri SHA1 karmasını kullanarak Git'ten bahsetti.

Öncelikle, nadiren (hiç değilse) günlük işlemlerde / çekimlerde hashlarla doğrudan ilgilenmeniz gerekir. Eğer fark ya da daha zorlu yeniden yapılanma parçalarından bazılarını yapıyorsanız, kütüğü yukarı çekmeniz ve hash çekmeniz gerekir.

Git ile herkes aynı karmaşaya sahiptir. Farklı havuzların farklı taahhüt numaraları yoktur ve herkes aynı sayfadadır. Hg ile bu daha az olur. Uygulamada, bağlılık değerlerini kaldırmanız ve onlarla birlikte çalışmanız gerekiyorsa (ya kodun zaman çizelgesini karşılaştırmak ya da çaprazlamak için), sayılar yerine eşyalarınız olduğunda diğer insanlarla eşitlemek daha kolaydır.

Hayır, lütfen canını sıkma bile.

Cidden, bir DVCS'den başlayın. SVN'nin popüler olması onu standart yapmaz. Linus Torvalds size beyninizi çürütebileceğini söylerdi . .

Joel Spolsky tarafından Subversion Re-education adı verilen bu harika makaleyi okuyun. .

Bu diğer soruyu okumak da ilginizi çekebilir: Ben bir Subversion geek'im, neden Mercurial, Git veya başka bir DVCS'yi göz önünde bulundurmalıyım?

DVCS'ler arasında seçim yapma

Şahsen ben hem mercurial hem git kullanıyorum ve ikisini de bilmenin önemli olduğunu düşünüyorum. Bununla ilgili tavsiye edilen bir okuma Git-Mercurial'dır: Lütfen Rahatlayın (git-addremove örneğine bakın). Bu yazıdan iki alıntıyı özetlediğimi düşünüyorum.

Git ile ilgili:

Git'in tasarım felsefesi kesinlikle Unix'e aittir: Subversion, CVS veya Mercurial'ın aksine git, tek yekpare bir ikili değil, git-pull, git-merge ve git-application, git-hash-object ve git-merge-file gibi düşük seviyeli “tesisat” komutlarına git-checkout. Böylece, MacGyver gibi Git ile ihtiyacınız olan her şeyi yapabilirsiniz - buna tamamen harika Wiki motorları, sorun izleyicileri, dosya sistemleri, sysadmin araçları - sigorta onarımı dışındaki her şey dahildir.

Mercurial ile ilgili olarak:

Sistemlerini temiz tutmak isteyen geliştiriciler muhtemelen hg'nin git'i oluşturan 144'ün aksine bir binary kurduğu gerçeğini ve git'in önceki taahhütlerinizi düzenleme yeteneğinin moronik, gereksiz ve tehlikeli olduğunu düşünen geliştiricileri takdir edecektir. sadelik hg, bu özel özelliği göz ardı ederek sağlar.

Github'da birçok proje bulunabilir ve git daha güçlüdür, ancak yeni gelenlere, özellikle de Windows kullanıcılarının gözünü korkutabilir. Ayrıca bitbucket (github'un mercurial için eşdeğeri) vardır.

Benim tavsiyem: mercurial ile başlayın ve onunla rahat hissettiğiniz anda git git; araçlarla ilgili değil, birlikte çalıştığınız insanlarla ilgili .

Subversion'un gerçek ve pratik kullanımı, diğer insanlarla çalışmak için değil, belki de üretim uygulamalarınız için bir güncelleyici uygulamaktır.

• Şu anda, svn neredeyse çoğu barındırma sağlayıcısına kuruluyor
• İyi alt proje desteğine sahiptir (şu anda git ve hg ile adreslenebilir). svn upprojeniz ve bağımlılıkları güncellenir.

Thorbjørn'un bu konuyla ilgili alıntı yapması :

DVCSes Subversion'a, Bittorrent'in ftp'ye ne olduğunu

Düzenleme : Git'ten önce bilmeniz gereken bir VCS varsa, Mercurial olabilir (çok daha kolay CLI arayüzü ve dağıtılmış kavramlarla tanışmak iyidir). Bu tavsiye özellikle Subversion'dan gelenler için geçerlidir, çünkü CLI bir dereceye kadar benzerdir. Dağıtılmış Sürüm Denetimi, Merkezi Sürüm Denetimi'nden daha kolay öğrenilebilir, çünkü istemci ve sunucu bölümleri ayrı değil, yalnızca depo örneğiniz hakkında endişelenirsiniz .

Ne kullanmayı düşündüğünüzü öğreniyor olmalısınız. Git popüler, tıpkı Mercurial'ın da popülerliği gibi. Git / Mercurial dağıtılmış kaynak kontrol sistemleridir.

Bir takıma yeni bir konsept getirirken en önemli şey (ve sürüm kontrolünün çok fazla ekip için yeni bir konu olarak görülmesi talihsizdir), hedeflerinizi ve değerlendirme kriterlerinizi belirlemenize yardımcı olur. Bunun hakkında resmi olmanız gerekmiyor, ancak kendinize aşağıdaki soruları sorun:

• Sürüm kontrolünün amacı nedir? bizim ekip. Evet, her şeye değer tüm sürüm kontrol sistemleri geçmişe geri dönmenize ve herhangi bir dosyada nelerin değiştiğini görmenize olanak sağlar. Ancak, yeni sürümleri referans almak için kullanacak mısınız? (kafanı salla, bunu istiyorsun). Bu, başarmak istediğiniz şeyin 2-3 satırlı vizyon ifadesidir.
• Ekibiniz daha sonraları dikkatlice birleştirmek için kendi yerel çalışma ortamlarına sahip mi? Öyleyse, DVCS yolu en anlamlı olabilir.
• Bunun tersine, ekibiniz tek bir paylaşılan sürücüden çalışmaya alışmış mı ve her şey sürekli entegrasyonda mı? Öyleyse, daha geleneksel VCS en mantıklı olabilir.

Alternatiflerinizi değerlendirirken, tüm VCS'nin yapması gereken önemli şeyleri göz önünde bulundurmalısınız:

• Temel kod (etiketli dallar, etiketler, vb.). Temel olarak, projenizin yayınlanmasında kullanılan kaynak kodunu nasıl elde edersiniz?
• Merkezi sunucuda yerel değişiklikleri alın. DVCS veya standart VCS kullanıyor olsanız da, kodun yetkili bir kopyası olmalıdır. Her araç bu işlemi farklı ele alır.
• Merkezi sunucuda değişiklikleri yerel kopyanıza alın.
• Deneysel değişikliklerle nasıl baş edilir. VCS, ana proje kaynak kodunu bozmadan önerilen değişikliklerle daha fazla cesaretli olmanıza izin verir. DVCS ve standart VCS sistemleri buna çok farklı yaklaşıyor - bunlardan biri ekibiniz için en iyi sonucu verecek.
• Sunucuları nasıl kurar ve yapılandırırsınız?
• Doğrulamaya ihtiyacınız var mı? Öyleyse, yalnızca değişiklik yapmasına izin verilen kişilerin gerçekten yapabileceklerinden nasıl emin olabilirsiniz?

Sonunda, standart VCS veya DVCS sistemlerinin ekibiniz için en iyi olup olmadığını belirlemek için hızlı bir değerlendirme yapın. En az acı veren aracı seçmeniz gerekecek, aksi takdirde kabul görmeyeceksiniz. Bundan sonra ihtiyaçlarınızı en iyi şekilde karşılayan alternatiflerinizi değerlendirin.

Sonunda ne kullanmayı planladığını öğren.

Bence birçok insan svn'den daha karmaşık buluyor çünkü farklı. Subversion (veya cvs, vb.) Bir süre kullanıldıktan sonra, modları zihinsel olarak DVCS modeline dönüştürmek zor olabilir. Buna dayanarak, git gibi bir DVCS araştırmasıyla paralel olarak, yıkım gibi geleneksel VCS'yi araştırmanın sizin için uygun olabileceğini söyleyebilirim.

Git benim tercih ettiğim VCS olmasına rağmen, yıkılmayı öğrenmenin de en iyisi olduğunu söyleyebilirim. Birincisi, hala bir gün ile etkileşime girmeniz gerekebilecek birçok yıkım ve cvs deposu var ve ayrıca DVCS'nin geleneksel VCS'ye göre kesin avantajlarını ve dezavantajlarını daha iyi anlayacaksınız.

Svn'yi ve ardından git'i öğrenmek ters-üretken olacaktır.

İşte birkaç neden:

• Gv svn den radikal biçimde farklı. Git dağıtılmış ve svn istemci / sunucu.
• Aynı kelimelere farklı anlamlar eklenir. Örneğin, 'git checkout ...', 'svn checkout ...' dan farklı bir anlama sahiptir.
• Dallanma farklı. Git, svn'nin desteklemediği ucuz yerel şubeler olan 'konu' dalları konseptine sahiptir.
• Git, çalışma ağacı ile deponuzun arasına giren, dizin adı verilen fazladan bir yere sahip. Svn'de indeks yok. Git'i kullanarak değişiklikleriniz çalışma ağacınızdan dizine depoya taşınır.

Benim tavsiyem sadece git öğrenmek.

GIT ve SVN’de aynı olan bazı şeyler var, bazıları değil.

Oluştur / güncelleme / ödeme / işlemek

Genel olarak aynı, kolayca almak gerekir.

nasıl etiketlenir ve dallanır, ancak dallar ve ana hatlar arasındaki çatışmalar hakkında hala çok fazla karıştı

İkisi arasında farklı.

Şimdi değişmeniz gerektiğini veya söylememeniz gerektiğini söylememek (bence bu sizin kararınız), bunu hesaba katmak için bir şey olarak belirtmek istedim. Git'i denemek istediğinizden eminseniz, SVN'de Git'te farklı bir şey öğrenerek kendinizi kurtarmak için şimdi geçiş yapmaya karar verebilirsiniz.

Vay; 12 cevap ve herkes hala soruya yalvarıyor ...

Hayır, Subversion Git için ön şart değil.

Subversion ve Git arasında net bir haritalama yoktur - ikisini de öğrenmeyi planlıyorsanız, farklı eylemler için aynı terimleri kullandıkları için acı çekmeniz gerekir. (Aynı eylemler için farklı terimler.)

• svn commitondan farklı bir şey git commit.
• svn ve git'teki şubeler çok farklı
• Bir svn deposu git uzaktan kumandası gibidir (ama aslında değil)
• git deposu bir svn çalışan kopyası gibi daha fazla (ama gerçekten değil)

Bunlar ortak bir dile bölünmüş iki araç.

Sorunuz ve diğer cevapların çoğu, git'in bir tür svn ++ olduğunu varsayalım; Bir "daha iyi svn". Değil. İkisi de aynı alanda çalışan araba ve motosiklet gibi farklı araçlardır.

Birini seçmeni, ustalaşmanı ve takımını kullanmaya başlamanı öneririm. Sürüm kontrolünü öğrenmek, daha önce kullanmayan insanlar için zor olacak. VCS'niz altyapınızın önemli bir parçası olacak ve güven duymayı öğrenmek yeni çalışma alışkanlıkları geliştirmeyi içeriyor. Bu biraz zaman alıyor.

(Her iki durumda da, sistem yöneticilerinizin ana veri havuzunu yedeklediğinizden emin olun - kaynak kontrolünüzü kaybetmeniz felaket olur.)

Muhtemelen hayır - sunucu tabanlı ve dağıtılmış arasında muhtemelen sadece kendinize daha fazla karıştıracağınız yeterli fark var.

İstediğiniz DVCS ile sıfırdan başlamışsınız gibi iyi uygulamaları takip etmeye başladığınızda muhtemelen çok daha mutlu olursunuz.

Git Mercurial'a bakın (boğulmak istemiyorsanız).

Git, Subversion'dan yalnızca marjinal bir şekilde daha karmaşık, çünkü Git'te merkezi depoya teslim olmakla itmek arasında bir fark var.

Subversion tarafından kararsız kalmanız için bir şansınız varken Git'i öğrenmeye değer.

Subversion'ı anlamak Git'i anlamak için gerekli sanmıyorum.

Git ve Mercurial ile Subversion arasındaki en büyük fark, en azından benim için, üzerinde çalıştığınız yerel bir depoya sahip olmanız, kodunuz çalışana kadar içeri ve dışarı girmeniz, merkezi depodan ödeme yapmanız, herhangi bir uyuşmazlığı gidermek ve tekrar kontrol edin ve sunucuya basın.

Unix ortamında gitmeyi gerçekten seviyorum (Linux, MacOS X). Pencerelerde, biraz hacky. Eğer denklemde Windows varsa, Mercurial'ı düşünürdüm.

Tarih derslerinizi beğendim, SCCS, RCS, CVS, Subversion'ı deneyin ve ardından Git veya Mercurial gibi faydalı bir şey kullanın.

Git ve Mercurial eşdeğerdir, Git'in büyük bonusu github'dur . Ancak sürüm kontrolünüzü dış kaynak olarak kullanmak istemiyorsanız, github artık denklemde değildir.

Versiyon kontrol sistemleri, programlama dilleri ile ortak olan bir şeyi paylaşır; çünkü ilk öğrendiğinizin çoğu zaman alacaktır. Ondan sonra, yeni bir tane seçmek, temel kavramların yeni sistem tarafından nasıl ifade edildiğini öğrenmekle ilgilidir.

Git'i şimdi öğrenebilir ve gerekirse Suvbersion'u öğrenmek için zaman harcayabilirsiniz.

Hayır! Git'i indirin, bir github hesabı oluşturun ve birkaç gün boyunca depoları kazanarak, vb. Etrafta dolaşın. Git hızlanmak için oldukça önemsizdir. 5 veya 6 bash komutunu öğrenin ve tüm gerekli görevleri yapabilirsiniz. Genelde bir GUI'nin "salak geçirmezliği" tercih ederim, ancak Git Bash ne kadar kolaydır? Ayrıca, bu rotayı tercih ederseniz, Git Gui oldukça iyi. SVN öğrenmekten göreceğiniz faydayı gerçekten görmüyorum. Bir süre önce yeni bir açık kaynaklı proje için birkaç farklı Sürüm Kontrol sistemini değerlendirdiğim bir dönemden geçtim. SVN, Bazaar, Git ve diğer birkaç kişiyi denedim ve her birinin temellerini öğrendim. YMMV ama Git oldu farkla en kolay. SVN öğrenmede de yanlış bir şey yoktur, ancak Git'i öğrenmenize gerçekten yardımcı olmaz.