Główna różnica polega na tym, że (jak już powiedziano w innych odpowiedziach) CVS jest (starym) scentralizowanym systemem kontroli wersji, podczas gdy Git jest rozproszony.
Ale nawet jeśli używasz kontroli wersji dla jednego programisty, na jednym komputerze (jednym koncie), istnieje kilka różnic między Git i CVS:
Konfigurowanie repozytorium . Git przechowuje repozytorium w .gitkatalogu w głównym katalogu twojego projektu; CVS wymaga skonfigurowania CVSROOT, centralnego miejsca do przechowywania informacji o kontroli wersji dla różnych projektów (modułów). Konsekwencją tego projektu dla użytkownika jest to, że importowanie istniejących źródeł do kontroli wersji jest tak proste, jak „git init && git add. && git commit” w Git, podczas gdy jest bardziej skomplikowane w CVS.
Operacje atomowe . Ponieważ CVS na początku był zbiorem skryptów wokół systemu kontroli wersji RCS dla poszczególnych plików, zatwierdzenia (i inne operacje) nie są atomowe w CVS; jeśli operacja na repozytorium zostanie przerwana w środku, repozytorium może pozostać w niespójnym stanie. W Gicie wszystkie operacje są atomowe: albo kończą się sukcesem, albo kończą się niepowodzeniem bez żadnych zmian.
Zestawy zmian . Zmiany w CVS dotyczą każdego pliku, podczas gdy zmiany (zatwierdzenia) w Git zawsze dotyczą całego projektu. To bardzo ważna zmiana paradygmatu . Jedną z konsekwencji tego jest to, że w Git bardzo łatwo jest cofnąć (stworzyć zmianę, która cofa) lub cofnąć całą zmianę; Inną konsekwencją jest to, że w CVS można łatwo wykonać częściowe wyewidencjonowanie, podczas gdy obecnie jest to prawie niemożliwe w Git. Fakt, że zmiany dotyczą poszczególnych plików, zgrupowanych razem, doprowadził do wynalezienia formatu GNU Changelog dla komunikatów o zatwierdzeniach w CVS; Użytkownicy Gita używają (a niektóre narzędzia Git oczekują) innej konwencji, z jedną linią opisującą (podsumowującą) zmianę, po której następuje pusta linia, po której następuje bardziej szczegółowy opis zmian.
Nazewnictwo rewizji / numerów wersji . Jest jeszcze jeden problem związany z faktem, że zmiany w CVS dotyczą plików: numery wersji (jak czasem można zobaczyć w rozszerzaniu słów kluczowych , zobacz poniżej), np. 1.4, odzwierciedlają ile razy dany plik był zmieniany. W Gicie każda wersja projektu jako całości (każde zatwierdzenie) ma swoją unikalną nazwę nadaną przez identyfikator SHA-1; Zwykle do zidentyfikowania zatwierdzenia wystarczą pierwsze 7-8 znaków (nie można zastosować prostego schematu numerowania wersji w rozproszonym systemie kontroli wersji - wymaga to centralnego numerowania). W CVS aby mieć numer wersji lub nazwę symboliczną odnoszącą się do stanu projektu jako całości, używasz tagów ; to samo dotyczy Gita, jeśli chcesz używać nazw takich jak 'v1.5.6-rc2' dla niektórych wersja projektu ... ale tagi w Git są dużo łatwiejsze w użyciu.
Łatwe rozgałęzianie . Gałęzie w CVS są moim zdaniem zbyt skomplikowane i trudne w obsłudze. Musisz oznaczyć gałęzie, aby mieć nazwę dla całej gałęzi repozytorium (a nawet to może się nie udać w niektórych przypadkach, jeśli dobrze pamiętam, z powodu obsługi poszczególnych plików). Dodaj do tego fakt, że CVS nie ma śledzenia scalania , więc musisz albo zapamiętać, albo ręcznie oznaczać punkty scalania i rozgałęzienia, i ręcznie podawać poprawne informacje dla "cvs update -j", aby scalić gałęzie. niepotrzebne trudne w użyciu. W Gicie tworzenie i łączenie gałęzi jest bardzo łatwe; Git sam zapamiętuje wszystkie wymagane informacje (więc scalanie gałęzi jest tak proste, jak „git merge nazwa gałęzi ”) ... musiał, ponieważ rozwój rozproszony w naturalny sposób prowadzi do wielu gałęzi.
Oznacza to, że możesz używać gałęzi tematycznych , tj. Opracowywać oddzielną funkcję w wielu krokach w oddzielnej gałęzi funkcji.
Zmień nazwę (i skopiuj) śledzenie . Zmiany nazw plików nie są obsługiwane w CVS, a ręczna zmiana nazwy może zepsuć historię na pół lub doprowadzić do nieprawidłowej historii, w której nie można poprawnie przywrócić stanu projektu przed zmianą nazwy. Git wykorzystuje heurystyczne wykrywanie zmian nazwy, oparte na podobieństwie zawartości i nazwy pliku (to rozwiązanie sprawdza się w praktyce). Możesz również zażądać wykrycia kopiowania plików. To znaczy że:
- badając podany commit, dostaniesz informację, że jakiś plik został zmieniony,
- scalanie poprawnie uwzględnia zmiany nazwy (np. jeśli plik został zmieniony tylko w jednej gałęzi)
- „git blame”, (lepszy) odpowiednik „cvs annotate”, narzędzia do wyświetlania historii zawartości pliku w wierszach, może śledzić ruchy kodu również po zmianie nazwy
Pliki binarne . CVS ma bardzo ograniczone wsparcie dla plików binarnych (np. Obrazów), wymagając od użytkowników wyraźnego oznaczania plików binarnych podczas dodawania (lub później przy użyciu "cvs admin", lub poprzez wrappery, aby robić to automatycznie na podstawie nazwy pliku), aby uniknąć zniekształcenia plik binarny poprzez konwersję końca linii i rozszerzenie słów kluczowych. Git automatycznie wykrywa plik binarny na podstawie zawartości w ten sam sposób, w jaki robią to CNU diff i inne narzędzia; możesz nadpisać to wykrycie używając mechanizmu gitattributes. Ponadto pliki binarne są zabezpieczone przed nieodwracalnym zniekształceniem dzięki domyślnemu ustawieniu `` safecrlf '' (i faktowi, że musisz zażądać konwersji końca linii, chociaż może to być domyślnie włączone w zależności od dystrybucji) oraz temu (ograniczone) słowo kluczowe ekspansja to ścisłe „opt-in” w Git.
Rozszerzenie słów kluczowych . Git oferuje bardzo, bardzo ograniczony zestaw słów kluczowych w porównaniu z CVS (domyślnie). Wynika to z dwóch faktów: zmiany w Git dotyczą repozytorium, a nie pliku, a Git unika modyfikowania plików, które nie uległy zmianie podczas przełączania na inną gałąź lub przewijania do innego punktu w historii. Jeśli chcesz osadzić numer wersji za pomocą Gita, powinieneś to zrobić używając swojego systemu budowania, np. Zgodnie z przykładem skryptu GIT-VERSION-GEN w źródłach jądra Linuksa i źródłach Git.
Zobowiązania korygujące . Ponieważ w rozproszonym systemie VCS, takim jak Git, publikacja jest niezależna od tworzenia zatwierdzenia, można zmienić (edytować, przepisać) niepublikowaną część historii bez przeszkadzania innym użytkownikom. W szczególności, jeśli zauważysz literówkę (lub inny błąd) w komunikacie zatwierdzenia lub błąd w zatwierdzeniu, możesz po prostu użyć polecenia „git commit --amend”. Nie jest to możliwe (przynajmniej nie bez silnego włamania) w CVS.
Więcej narzędzi . Git oferuje znacznie więcej narzędzi niż CVS. Jedną z ważniejszych jest „ git bisect ”, której można użyć do znalezienia zatwierdzenia (poprawki), które wprowadziło błąd; jeśli twoje zatwierdzenia są małe i niezależne, powinno być dość łatwo wtedy odkryć, gdzie jest błąd.
Jeśli współpracujesz z co najmniej jednym innym deweloperem, zauważysz również następujące różnice między Git i CVS:
Zatwierdź przed scaleniem Git używa raczej zatwierdzenia przed scaleniem niż, jak CVS, scalenia przed zatwierdzeniem (lub zaktualizuj-potem-zatwierdzenie ). Jeśli podczas edytowania plików, przygotowań do stworzenia nowego zatwierdzenia (nowej rewizji), ktoś inny utworzył nowe zatwierdzenie w tej samej gałęzi i znajduje się on teraz w repozytorium, CVS zmusza cię do aktualizacji katalogu roboczego i rozwiązywania konfliktów przed zezwoleniem na zatwierdzenie. Tak nie jest w przypadku Git. Najpierw zatwierdzasz, zapisujesz stan w kontroli wersji, a następnie scalasz inne zmiany programisty. Możesz również poprosić innego programistę o scalenie i rozwiązanie konfliktów.
Jeśli wolisz mieć historię liniową i unikać scalania, zawsze możesz użyć przepływu pracy zatwierdzania-łączenia- ponownego uruchamiania poprzez „git rebase” (i „git pull --rebase”), który jest podobny do CVS, ponieważ odtwarza zmiany zaktualizowanego stanu. Ale zawsze zobowiązujesz się pierwszy.
Nie ma potrzeby posiadania centralnego repozytorium Dzięki Git nie ma potrzeby posiadania jednego centralnego miejsca, w którym zatwierdzasz zmiany. Każdy programista może mieć swoje własne repozytorium (lub lepsze repozytoria: prywatne, w którym zajmuje się programowaniem, i publiczne, w którym publikuje gotową część) i może pobierać / pobierać z innych repozytoriów, w symetryczny fason. Z drugiej strony w przypadku większego projektu często występuje społecznie zdefiniowane / nominowane centralne repozytorium, z którego wszyscy czerpią (pobierają zmiany).
Wreszcie Git oferuje znacznie więcej możliwości, gdy potrzebna jest współpraca z dużą liczbą programistów. Poniżej znajdują się różnice między CVS w Git dla różnych etapów zainteresowania i pozycji w projekcie (pod kontrolą wersji przy użyciu CVS lub Git):
czai się . Jeśli jesteś zainteresowany tylko pobieraniem najnowszych zmian z projektu ( bez propagowania twoich zmian ) lub tworzeniem własnych programów (bez wnoszenia wkładu w oryginalne projekty); lub wykorzystujesz projekty zagraniczne jako podstawę własnego projektu (zmiany są lokalne i nie ma sensu ich publikować).
Git obsługuje tutaj anonimowy, nieuwierzytelniony dostęp tylko do odczytu za pośrednictwem niestandardowego wydajnego git://protokołu lub jeśli jesteś za blokowaniem zapory DEFAULT_GIT_PORT(9418), możesz użyć zwykłego protokołu HTTP.
Dla CVS najczęstszym rozwiązaniem (jak rozumiem) dla dostępu tylko do odczytu jest konto gościa dla protokołu „pserver” na CVS_AUTH_PORT(2401), zwykle nazywane „anonimowym” i z pustym hasłem. Poświadczenia są domyślnie przechowywane w $HOME/.cvspasspliku, więc musisz podać je tylko raz; nadal jest to trochę bariera (musisz znać nazwę konta gościa lub zwracać uwagę na wiadomości serwera CVS) i irytację.
programiści (twórca liści) . Jednym ze sposobów propagowania zmian w OSS jest wysyłanie poprawek pocztą elektroniczną . Jest to najczęstsze rozwiązanie, jeśli jesteś (mniej lub bardziej) przypadkowym programistą, wysyłając pojedynczą zmianę lub pojedynczą poprawkę błędu. BTW. wysyłanie poprawek może odbywać się przez komisję recenzentów (system recenzji poprawek) lub w podobny sposób, nie tylko pocztą elektroniczną.
Git oferuje tutaj narzędzia, które pomagają w tym mechanizmie propagacji (publikowania) zarówno dla nadawcy (klienta), jak i dla opiekuna (serwer). Dla osób, które chcą wysyłać swoje zmiany e-mailem, istnieje narzędzie " git rebase " (lub "git pull --rebase") do odtwarzania własnych zmian na podstawie aktualnej wersji, więc zmiany są na górze aktualnej wersji (są świeże ) i „ git format-patch ” do tworzenia wiadomości e-mail z komunikatem zatwierdzenia (i autorstwa), zmiana w postaci (rozszerzonego) zunifikowanego formatu różnic (plus diffstat dla łatwiejszego przeglądu). Maintainer może przekształcić taki e-mail bezpośrednio w zatwierdzenie, zachowując wszystkie informacje (w tym komunikat o zatwierdzeniu) za pomocą polecenia „ git am ”.
CVS nie oferuje takich narzędzi: możesz użyć "cvs diff" / "cvs rdiff" do generowania zmian i użyć łaty GNU do ich zastosowania, ale o ile wiem, nie ma sposobu na zautomatyzowanie stosowania komunikatu zatwierdzenia. CVS miał być używany w stylu klient <-> serwer ...
poruczniku . Jeśli jesteś opiekunem oddzielnej części projektu (podsystemu) lub jeśli rozwój twojego projektu przebiega zgodnie z przepływem pracy "sieci zaufania" używanym przy tworzeniu jądra Linuksa ... lub po prostu jeśli masz własne repozytorium publiczne, a zmiany to które chcesz opublikować są zbyt duże, aby wysłać je e-mailem jako serię poprawek , możesz wysłać żądanie ściągnięcia do (głównego) opiekuna projektu.
Jest to rozwiązanie specyficzne dla rozproszonych systemów kontroli wersji, więc oczywiście CVS nie obsługuje takiego sposobu współpracy. Jest nawet narzędzie o nazwie „git request-pull”, które pomaga przygotować e-mail do wysłania do opiekuna z prośbą o pobranie z repozytorium. Dzięki „pakietowi git” możesz korzystać z tego mechanizmu nawet bez publicznego repozytorium, wysyłając pakiet zmian e-mailem lub przez sneakernet. Niektóre witryny hostingowe Git, takie jak GitHub , obsługują powiadamianie, że ktoś pracuje (opublikował jakąś pracę) nad Twoim projektem (pod warunkiem, że korzysta z tej samej witryny hostingowej Git), a także umożliwiają wysyłanie do PM typu żądania ściągnięcia.
główny programista , czyli ktoś, kto bezpośrednio publikuje swoje zmiany (w repozytorium głównym / kanonicznym). Ta kategoria jest szersza dla rozproszonych systemów kontroli wersji, ponieważ posiadanie wielu programistów z dostępem do zapisu w centralnym repozytorium to nie tylko możliwy przepływ pracy (możesz mieć jednego opiekuna, który wypycha zmiany do repozytorium kanonicznego, zestawu poruczników / opiekunów podsystemów, z których on / ona pulls i szeroka gama deweloperów-liści, którzy wysyłają łaty pocztą albo do opiekunów / listy mailingowej projektu, albo do jednego z poruczników / podrzędnych opiekunów).
Dzięki Git możesz używać protokołu SSH ( protokół git zawinięty w SSH) do publikowania zmian, z narzędziami takimi jak „git shell” (w celu zwiększenia bezpieczeństwa, ograniczenia dostępu do kont powłoki) lub Gitosis (w celu zarządzania dostępem bez konieczności posiadania oddzielnych kont powłoki ) i HTTPS z WebDAV ze zwykłym uwierzytelnianiem HTTP.
W CVS istnieje możliwość wyboru między niestandardowym nieszyfrowanym (zwykłym tekstem) pserver protokołem lub użyciem zdalnej powłoki (gdzie naprawdę powinieneś używać SSH ) do publikowania zmian, co w przypadku scentralizowanego systemu kontroli wersji oznacza zatwierdzanie zmian (tworzenie zatwierdzeń). Cóż, możesz również tunelować protokół „pserver” za pomocą SSH, a istnieją narzędzia innych firm, które to automatyzują… ale nie sądzę, aby było to tak proste, jak np. Gitosis.
Ogólnie rozproszone systemy kontroli wersji, takie jak Git, zapewniają znacznie szerszy wybór możliwych przepływów pracy. W przypadku scentralizowanych systemów kontroli wersji, takich jak CVS, z konieczności musisz rozróżniać osoby z dostępem do repozytorium przez zatwierdzanie, a tymi, którzy nie mają ... zatwierdzić dostęp.