Temel fark, (diğer yanıtlarda da söylendiği gibi) CVS'nin (eski) merkezi sürüm kontrol sistemidir, oysa Git dağıtılır.
Ancak, tek bir makinede (tek hesap) tek geliştirici için sürüm kontrolünü kullansanız bile, Git ve CVS arasında birkaç fark vardır:
Depo kuruluyor . Git, depoyu .gitprojenizin üst dizinindeki dizinde depolar ; CVS, farklı projeler (modüller) için sürüm kontrol bilgilerini depolamak için merkezi bir yer olan CVSROOT'un kurulmasını gerektirir. Kullanıcı için bu tasarımın sonucu, mevcut kaynakların sürüm kontrolüne aktarılmasının Git'te "git init && git add. && git commit" kadar basit, CVS'de ise daha karmaşık olmasıdır .
Atomik işlemler . Başlangıçta CVS, dosya başına RCS sürüm kontrol sistemi etrafında bir dizi betik olduğundan, taahhütler (ve diğer işlemler) CVS'de atomik değildir; Depodaki bir işlem ortada kesintiye uğrarsa, depo tutarsız bir durumda bırakılabilir. Git'te tüm işlemler atomiktir: ya bütün olarak başarılı olurlar ya da herhangi bir değişiklik olmadan başarısız olurlar.
Değişiklik kümeleri . CVS'deki değişiklikler dosya başınadır, Git'teki değişiklikler (taahhütler) ise her zaman tüm projeyi ifade eder. Bu çok önemli bir paradigma değişimidir . Bunun sonuçlarından biri, Git'te geri dönmenin (geri alan bir değişiklik yaratmanın) veya tüm değişikliği geri almanın çok kolay olmasıdır ; diğer bir sonuç da, CVS'de kısmi kontroller yapmanın kolay olmasına karşın, şu anda Git'te neredeyse imkansız olmasıdır. Değişikliklerin dosya başına olması, birlikte gruplandırılması gerçeği, CVS'deki commit mesajları için GNU Changelog formatının icat edilmesine yol açtı; Git kullanıcıları, değişikliği açıklayan (özetleyen) tek satır, ardından boş bir satır ve ardından değişikliklerin daha ayrıntılı açıklamasıyla farklı kurallar kullanır (ve bazı Git araçları bekler).
Revizyonları / sürüm numaralarını adlandırmak . CVS'de değişikliklerin dosya başına olmasıyla bağlantılı başka bir sorun daha var: sürüm numaraları (bazen anahtar kelime genişletmede görebileceğiniz gibi, aşağıya bakın), verilen dosyanın kaç kez değiştirildiğini yansıtır. Git'te bir projenin her sürümünün bir bütün olarak (her işleme), SHA-1 kimliği tarafından verilen benzersiz adı vardır; genellikle ilk 7-8 karakter bir kaydetmeyi tanımlamak için yeterlidir (merkezi numaralandırma yetkisi gerektiren dağıtılmış sürüm kontrol sistemindeki sürümler için basit numaralandırma şeması kullanamazsınız). CVS'de, bir bütün olarak projenin durumuna atıfta bulunan sürüm numarası veya sembolik ada sahip olmak için etiketleri kullanırsınız; bir projenin bazı sürümleri için 'v1.5.6-rc2' gibi bir ad kullanmak istiyorsanız aynı şey Git'te de geçerlidir ... ancak Git'teki etiketlerin kullanımı çok daha kolaydır.
Kolay dallanma . CVS'deki şubeler bence aşırı karmaşık ve uğraşması zor. Dalları, tüm bir depo dalı için bir ada sahip olacak şekilde etiketlemeniz gerekir (ve hatta bazı durumlarda, doğru hatırlıyorsam, dosya başına işleme nedeniyle bu başarısız olabilir). Buna CVS'nin birleştirme izleme özelliğine sahip olmadığı gerçeğini de ekleyin; bu nedenle, birleştirme ve dallanma noktalarını hatırlamanız veya manuel olarak etiketlemeniz ve dalları birleştirmek için "cvs update -j" için doğru bilgileri manuel olarak sağlamanız gerekir ve bu, dallanmayı sağlar. gereksiz, kullanımı zor. Git'te dal oluşturmak ve birleştirmek çok kolaydır; Git gerekli tüm bilgileri kendi başına hatırlar (bu nedenle bir dalı birleştirmek "git birleştirme dal adı " kadar kolaydır ) ... bunu yapmak zorundaydı çünkü dağıtılmış geliştirme doğal olarak birden çok dala yol açar.
Bu, konu dallarını kullanabileceğiniz anlamına gelir , yani ayrı özellik dalında birden çok adımda ayrı bir özellik geliştirebilirsiniz.
İzlemeyi yeniden adlandırın (ve kopyalayın) . Dosya yeniden adları CVS'de desteklenmez ve manuel yeniden adlandırma, geçmişi ikiye bölebilir veya yeniden adlandırmadan önce bir projenin durumunu doğru şekilde kurtaramayacağınız geçersiz geçmişe neden olabilir. Git, içerik ve dosya adının benzerliğine dayalı olarak sezgisel yeniden adlandırma algılamasını kullanır (Bu çözüm pratikte iyi çalışır). Dosyaların kopyalanmasının algılanmasını da talep edebilirsiniz. Bunun anlamı şudur ki:
- belirtilen kaydetmeyi incelerken, bazı dosyanın yeniden adlandırıldığı bilgisini alırsınız,
- doğru bir şekilde birleştirildiğinde yeniden adlar dikkate alınır (örneğin, dosya yalnızca bir dalda yeniden adlandırılmışsa)
- Bir dosya içeriğinin satır bazında geçmişini gösteren bir araç olan "cvs annotate" in (daha iyi) eşdeğeri olan "git blame", yeniden adlarda da kod hareketini takip edebilir
İkili dosyalar . CVS, ikili dosyalar (ör. Görüntüler) için yalnızca çok sınırlı bir desteğe sahiptir ve kullanıcıların, karışıklıktan kaçınmak için ikili dosyaları eklerken (veya daha sonra "cvs admin" kullanarak veya bunu otomatik olarak yapmak için sarmalayıcılar aracılığıyla) açıkça işaretlemesini gerektirir. satır sonu dönüştürme ve anahtar kelime genişletme yoluyla ikili dosya. Git, CNU diff ve diğer araçların yaptığı gibi, içeriğe dayalı olarak ikili dosyayı otomatik olarak algılar; gitattributes mekanizmasını kullanarak bu algılamayı geçersiz kılabilirsiniz. Üstelik ikili dosyalar, 'safecrlf' varsayılanı (ve dağıtıma bağlı olarak varsayılan olarak açılmış olsa da hat sonu dönüştürme istemeniz gerektiği gerçeği) ve bu (sınırlı) anahtar kelime sayesinde kurtarılamayan karıştırmaya karşı güvenlidir. genişletme, Git'te katı bir 'seçmedir'.
Anahtar kelime genişletme . Git, CVS'ye kıyasla (varsayılan olarak) çok, çok sınırlı bir anahtar kelime kümesi sunar. Bunun nedeni iki olgudur: Git'teki değişiklikler dosya başına değil depo başına yapılır ve Git, başka bir dala geçerken veya geçmişte başka bir noktaya geri sarılırken değişmeyen dosyaları değiştirmekten kaçınır. Revizyon numarasını Git kullanarak gömmek istiyorsanız, bunu derleme sisteminizi kullanarak yapmalısınız, örneğin Linux çekirdek kaynaklarında ve Git kaynaklarında aşağıdaki GIT-VERSION-GEN komut dosyası örneği.
Taahhütleri değiştirme . Git gibi dağıtılmış VCS'de yayınlama eylemi bir kaydetme oluşturmaktan ayrı olduğundan, diğer kullanıcıları rahatsız etmeden geçmişin yayınlanmamış kısımlarını değiştirebilir (düzenleyebilir, yeniden yazabilir). Özellikle commit mesajında yazım hatası (veya başka bir hata) ya da commit'de bir hata fark ederseniz, "git commit --amend" i kullanabilirsiniz. CVS'de bu mümkün değildir (en azından ağır bilgisayar korsanlığı olmadan).
Daha fazla araç . Git, CVS'den çok daha fazla araç sunar. Daha da önemlisi, hata veren bir commit (revizyon) bulmak için kullanılabilen " git bisect " dir; Eğer taahhütleriniz küçükse ve kendi kendine yetiyorsa, hatanın nerede olduğunu keşfetmek oldukça kolay olacaktır.
En az bir başka geliştiriciyle işbirliği yapıyorsanız, Git ve CVS arasında aşağıdaki farklılıkları da bulacaksınız:
Son olarak Git, çok sayıda geliştiriciyle işbirliğine ihtiyaç duyulduğunda çok daha fazla olanak sunar. Aşağıda, bir projedeki farklı ilgi aşamaları ve pozisyon için Git'teki CVS arasında farklılıklar vardır (CVS veya Git kullanılarak sürüm kontrolü altında):
pusuda . Yalnızca bir projeden en son değişiklikleri almakla ( değişikliklerinizin yayılması olmadan ) veya özel geliştirme yapmakla ilgileniyorsanız (orijinal projelere katkıda bulunmadan); veya yabancı projeleri kendi projenizin temeli olarak kullanırsınız (değişiklikler yereldir ve bunları yayınlamak mantıklı değildir).
Git burada özel verimli protokol aracılığıyla anonim, kimliği doğrulanmamış salt okunur erişimi destekler git://veya güvenlik duvarı engellemesinin DEFAULT_GIT_PORT(9418) arkasındaysanız düz HTTP'yi kullanabilirsiniz.
CVS için salt okunur erişim için en yaygın çözüm (anladığım kadarıyla) , (2401) üzerindeki 'pserver' protokolü için misafir hesabıdırCVS_AUTH_PORT , genellikle "anonim" olarak adlandırılır ve boş parola ile. Kimlik bilgileri varsayılan olarak $HOME/.cvspassdosyada saklanır , bu nedenle yalnızca bir kez sağlamanız gerekir; yine de, bu biraz engel (misafir hesabının adını bilmeniz veya CVS sunucu mesajlarına dikkat etmeniz gerekir) ve rahatsızlıktır.
saçak geliştirici (yaprak katkısı) . OSS'deki değişikliklerinizi yaymanın bir yolu, yamaları e-posta yoluyla göndermektir . Bu, yanlışlıkla geliştiriciyseniz (aşağı yukarı), tek değişiklik veya tek hata düzeltme gönderiyorsanız en yaygın çözümdür. BTW. Yama göndermek yalnızca e-posta yoluyla değil, inceleme panosu (yama inceleme sistemi) veya benzer yollarla olabilir.
Git burada hem gönderen (istemci) hem de bakımcı (sunucu) için bu yayılma (yayınlama) mekanizmasında yardımcı olan araçlar sunar. Değişikliklerini e-posta yoluyla göndermek isteyen kişiler için, kendi değişikliklerinizi mevcut yukarı akış sürümünün üzerine yeniden oynatmak için " git rebase " (veya "git pull --rebase") aracı vardır, böylece değişiklikleriniz mevcut sürümün üstündedir (yenidir) ) ve kaydetme mesajı (ve yazarlık) içeren e-posta oluşturmak için " git format-patch ", (genişletilmiş) birleşik fark biçimi biçiminde değişiklik (artı daha kolay inceleme için diffstat). Maintainer, bu tür bir e-postayı " git am " kullanarak tüm bilgileri (commit mesajı dahil) koruyarak doğrudan commit haline getirebilir .
CVS böyle bir araç sunmaz: değişiklikleri oluşturmak için "cvs diff" / "cvs rdiff" kullanabilir ve değişiklikleri uygulamak için GNU yamasını kullanabilirsiniz, ancak bildiğim kadarıyla commit mesajını uygulamayı otomatikleştirmenin bir yolu yoktur. CVS, istemci <-> sunucu tarzında kullanılmak üzere tasarlanmıştı ...
teğmen . Bir projenin (alt sistemin) ayrı bir bölümünün bakımcısıysanız veya projenizin geliştirilmesi Linux çekirdeğinin geliştirilmesinde kullanılan "güven ağı" iş akışını takip ediyorsa ... veya sadece kendi genel deponuz varsa ve yayınlamak istiyorsanız yama serisi olarak e-posta ile gönderilemeyecek kadar büyükse , projenin (ana) koruyucusuna çekme isteği gönderebilirsiniz .
Bu, dağıtılmış sürüm kontrol sistemlerine özgü bir çözümdür , dolayısıyla CVS bu tür bir işbirliğini desteklemez. Deponuzdan veri çekme isteği ile bakım görevlisine gönderilecek e-postayı hazırlamaya yardımcı olan "git request-pull" adlı bir araç bile var. "Git paketi" sayesinde, e-posta veya sneakernet yoluyla değişiklik paketi göndererek, herkese açık depoya sahip olmadan da bu mekanizmayı kullanabilirsiniz. GitHub gibi bazı Git barındırma siteleri , birisinin projenizde çalıştığını (bazı çalışmalar yayınladığını) bildirme (aynı Git barındırma sitesini kullanması koşuluyla) ve bir tür çekme isteğine PM-ing için destek sağlar.
ana geliştirici , yani değişikliklerini doğrudan yayınlayan biri (ana / kanonik depoya). Bu kategori, dağıtılmış sürüm kontrol sistemleri için daha geniştir, çünkü merkezi depoya yazma erişimi olan birden fazla geliştiriciye sahip olmak yalnızca olası iş akışı değildir ( değişiklikleri kanonik depoya iten tek bir bakıcıya, bir dizi yardımcı / alt sistem koruyucusuna sahip olabilirsiniz. posta yoluyla ya bakımcı / proje posta listesine ya da teğmenlerden / alt bakıcılardan birine posta yoluyla yama gönderen çok çeşitli yaprak geliştiricileri).
Git ile değişiklikleri yayınlamak için SSH protokolünü (SSH'ye sarılmış git protokolü), "git shell" (güvenliğe yardımcı olmak, kabuk hesaplarına erişimi sınırlandırmak için) veya Gitosis (ayrı kabuk hesapları gerektirmeden erişimi yönetmek için ) kullanma seçeneğine sahipsiniz. ) ve WebDAV ile HTTPS , sıradan HTTP kimlik doğrulaması ile.
CVS ile, özel şifrelenmemiş (düz metin) pserver protokolü veya değişikliklerinizi yayınlamak için uzak kabuk (gerçekten SSH'yi kullanmanız gereken yer) kullanmak arasında bir seçim vardır ; bu, merkezi sürüm kontrol sistemi için değişikliklerinizi yapmak (taahhütler oluşturmak) anlamına gelir. SSH'yi kullanarak 'pserver' protokolünü de tünelleyebilirsiniz ve bunu otomatikleştiren üçüncü taraf araçları vardır ... ancak bunun Gitosis kadar kolay olduğunu sanmıyorum.
Genel olarak, Git gibi dağıtılmış sürüm kontrol sistemleri, olası iş akışlarının çok daha geniş bir seçimini sağlar. CVS gibi merkezi sürüm kontrol sistemlerinde, zorunlu olarak, depoya kesin erişim yetkisi olan ve olmayanlar arasında ayrım yapmanız gerekir ... ve CVS, olmayan kişilerin katkılarını (yamalar aracılığıyla) kabul etmeye yardımcı olacak herhangi bir araç sunmaz. erişim işlemek.