Z pewnością większość osób zajmujących się zawodowo informatyką napotkało już w swoim życiu na termin systemu kontroli wersji, stąd nie będę go tutaj wyjaśniał. W tym artykule postaram się pobieżnie przedstawić różnice pomiędzy dwoma bardzo popularnymi i darmowymi systemami: SVN (Subversion) i Git.
Subversion powstał na potrzeby eliminacji wad starszego systemu, jakim jest CVS (Concurrent Versions System). Najistotniejsze z nich to np. nieatomowe dokonywanie zmian w repozytorium (jeśli operacja była przerywana w trakcie wysyłania danych na serwer dochodziło do sytuacji, że część plików zostało wysłanych, a reszta nie) lub brak obsługi zmian nazw plików (plik o zmienionej nazwie był widziany jako usunięcie pliku o starej nazwie i utworzenie pliku o nowej). SVN rozwiązywał te problemy i dodatkowo był znacząco wydajniejszym rozwiązaniem. Z czasem SVN bardzo mocno spopularyzował się i zaowocował w szeregu rozmaitych narzędzi pomocniczych, wizualizujących zmiany, czy zwyczajnie ułatwiających pracę (jak np. popularny TortoiseSVN).
Git to projekt powstały w 2005 roku na cele rozwoju jądra Linuksa. Jego pierwszym autorem jest sam Linus Torvalds, czyli twórca systemu Linux. Linuksowcy poszukiwali wtedy zastępstwa dla nieotwartego rozwiązania BitKeeper, jakiego używali do tej pory do synchronizacji swojej pracy. Chcieli systemu zdecentralizowanego, a że nie było wtedy zbyt wielu takich na rynku, zdecydowali się użyć własnego. Git początkowo zdobywał popularność przez sam fakt, że jego twórca jest tak poważaną postacią w świecie informatyki. Z czasem jednak coraz szerzej mówiło się o jego rozsądnej koncepcji, a także dobrych firmach hostingowych zajmujących się przechowywaniem wyłącznie kodu, a używających gita, takich jak Github czy Bitbucket.
Różnice pomiędzy SVN a Git
Przede wszystkim SVN i Git nie są konkurencyjnymi rozwiązaniami. Oczywiście gdy rozpoczynamy wieloosobowy projekt najczęściej chcemy, aby użyć jednego systemu kontroli wersji i musimy wybrać nam odpowiadający, ale SVN i Git spełniają na tyle różne wymagania, że nie można powiedzieć, że ze sobą konkurują (jak motorówka i skuter, choć oba są środkami transportu). Osobiście uważam pytania typu "który z nich jest lepszy" za pozbawione sensu z tego właśnie powodu. Z powodu podstawowego niedopowiedzenia: "lepszy do czego?".
SVN to system scentralizowany. To oznacza, że jest jeden serwer, gdzie nie tylko znajduje się kod i jego historia, nie tylko to on jest odpowiedzialny za dbanie o zbieranie danych od użytkowników (ich kodu), ale także i on wykonuje wszystkie operacje zmieniające stan repozytorium. To znaczy, że użytkownik jest tzw. cienkim klientem, który wysyła tylko komendy co zrobić z kodem do serwera (stworzyć branch, wykonać merge, dokonać commitu itp). Program użytkownika jest zwolniony z większości mechanizmów obsługi tych operacji - robi je serwer. Tak samo jest z historią - aby sprawdzić historię zmian pytamy serwer. Na dysku twardym użytkownika znajduje się tylko kopia robocza plików, które użytkownik może swobodnie modyfikować. To oznacza, że jest to ostateczny stan repozytorium z perspektywy danej osoby (czyli np. wynikowy stan jakiegoś brancha).
Git to system zdecentralizowany. Z założenia ma działać bez udziału serwera. Ba, on nawet ma być w stanie odtworzyć całe repozytorium, z całą historią, w przypadku utraty oryginalnego źródła. Choć większość firm używa go i tak jak system scentralizowany, to jest to cecha, której niezrzeszeni w korporacji twórcy Linuksa potrzebowali. Oznacza to zarówno, że historia zmian nie przepadnie razem z serwerem, ale także i możliwość pracy bez jego udziału. W związku z celem realizacji takiego zadania Git przechowuje u użytkownika dwie rzeczy: repozytorium (cała historia wszystkich zmian wszystkich branchy) i kopię roboczą (stan wynikowy plików). W przypadku dynamicznie rozwijającego się projektu zajmuje to dużo miejsca na dysku użytkownika, ale daje mu niezależność. Operacje są wykonywane u użytkownika i to ona ma do tego odpowiednie oprogramowanie. Serwer otrzymuje tylko informacje o stanie, jeśli użytkownik sobie tego zażyczy. W związku z tym utworzenie brancha, zmiana brancha, merge, czy commit zachodzi w pełni lokalnie. Serwer można poinformować poprzez "wypchnięcie zmian" (komenda push). Synchronizacja stanu swojego repozytorium lokalnego z tym na serwerze (ściągnięcie zmian innych użytkowników) odbywa się także tylko na żądanie (komenda pull).
Źródło obrazka
Poniższa tabelka przedstawia zarówno różnice, jakie wynikają ze wspomnianej (de-)centralizacji, jak i inne fakty o tych dwóch rozwiązaniach.
| SVN | Git |
|---|---|
| Użytkownik zużywa mało miejsca na dysku aby operować na projekcie. | Użytkownik potrzebuje dużo miejsca na dysku aby działać. |
| Użytkownik może ściągnąć dowolny katalog repozytorium i operować tylko na nim. | Użytkownik musi ściągnąć całe repozytorium projektu. |
| Konieczna jest komunikacja z serwerem aby sprawdzić historię zmian, dokonać merge, stworzyć branch itp. | Zmiany dokonywane są lokalnie, użytkownik robi je we własnym repozytorium. |
| Użytkownik może posiadać zmiany tylko dla jednego brancha dopóki nie wyśle ich na serwer. | Lokalne repozytorium pozwala dokonywać szeregu zmian na różnych branchach i potem poinformować serwer o nich wszystkich. |
| Praca bez połączenia z siecią jest możliwa tylko do etapu gdy nie potrzebujemy wykonać operacji na systemie wersji. Możemy więc edytować pliki, ale już sam commit jest niemożliwy. | Praca bez połączenia z siecią jest możliwa. Repozytorium oczywiście z czasem zaczyna jednak coraz mocniej odbiegać od repozytoriów innych użytkowników, więc konieczna będzie synchronizacja. W modelu pracy gdzie nigdy nie pracujemy w miejscach bez dostępu do sieci/serwera nie ma znaczącej różnicy w tej kwestii. |
| Branch i merge jest odrobinę wolniejszy i nieco trudniejszy. Jeśli chodzi o różnicę prędkości nadal mówimy tu jednak o prędkości rzędu 0.093 sekudny na SVN kontra 0.031 sekundy na Git (test wykonany na repozytorium kodu Wordpress). | Branch i merge jest odrobinę szybszy i łatwiejszy w użyciu. |
| Operowanie na plikach binarnych (nie tekstowych) jest wysoce zoptymalizowane. Wykrywane są różnice w plikach binarnych i tylko różnice są wersjonowane, co optymalnej wykorzystuje miejsce na dysku po stronie repozytorium (szczególnie w przypadku dużych plików). Jest wsparcie dla kompresji transmisji itp. | Operowanie na plikach binarnych jest mniej wydajne i optymalne. Zużywa więcej miejsca w repozytorium (tam, gdzie przechowywana jest cała historia plików). |
| Znaki returnów (końców linii) wysyłane są na serwer bez zmian. Analogicznie ze ściąganiem ich z serwera. | Standardowym zachowaniem jest zamiana returnów na standard obowiązujący u użytkownika w locie. |
| Zestaw narzędzi ułatwia pracę także osobom nie zajmującym się programowaniem. Nie ma przeszkód aby cała firma używała repozytoriów do różnych celów. Nawet takich jak wersjonowanie kolekcji zdjęć. | Dotychczasowe zestawy narzędzi są mocno ukierunkowane w stronę wytwarzania oprogramowania. Mogą stanowić problem dla osób nie mających z nim związku. Sporą cześć operacji najwygodniej wykonuje się z konsoli (używając komendy git). |
| Serwer (repozytorium) wymaga wyjątkowo mało zasobów (CPU i RAM) i jest łatwy do uruchomienia na mało wydajnych urządzeniach. | Serwer wymaga nieco więcej zasobów i jest nieznacznie trudniejszy do zainstalowania i skonfigurowania. |
| Użytkowanie można rozpocząć po bardzo prostym szkoleniu. | Obsługa git wbrew pozorom nie jest trudna, ale wymaga od większości osób poświęcenia większej ilości czasu ze względu na potrzebę zrozumienia kroków pośrednich (np. commit nie sprawia, że koledzy zobaczą zmiany, należy je jeszcze wysłać do serwera, czyli wykonać push). |
| Nie posiada funkcji stash. Potrzebne jest ręczne generowanie plików patch aby tymczasowo przechować zmiany, jeśli ktoś posiada taką potrzebę. | Umożliwia odłożenie wszystkich niezcommitowanych zmian na tzw. stash i powrócenie do stanu sprzed nich. To pozwala "schować" zmiany na potem i przeskoczyć do innego zadania na chwilę. Zmiany odłożone na stash potem bardzo łatwo przywrócić. |
| Rewizje są numerowane. | Rewizje są oznaczane kodami SHA-1 (litery i cyfry, bez kolejności). |
| Kody błędów są zazwyczaj czytelne. | Błędy bywają niezrozumiałe w niektórych zaawansowanych przypadkach. |
| Ustawienie plików ignorowanych jest upubliczniane na serwerze dla innych użytkowników. | Ignorowane pliki mogą być ustawiane prywatnie, tylko dla danego użytkownika. |
| Nadpisanie historii jest niemożliwe z perspektywy użytkownika. Wymaga to trudnej administracyjnej interwencji po stronie serwera. W SVN jest to uznawane za punkt bezpieczeństwa. | Użytkownik ma możliwość zmian historii. Ułatwia to proces permanentnego usuwania danych prywatnych nieopatrznie wrzuconych na serwer (np. hasło, dane osobowe klienta). |
| Możliwe jest granularne przydzielanie praw użytkowników do odczytu i zapisu do poszczególnych katalogów projektu. | Prawa przydzielane są do całych repozytoriów. |
| Zmiana nazwy pliku i jednocześnie jego modyfikacja jest lepiej wykrywana. | Przy zmianie nazwy pliku i jego jednoczesnej modyfikacji przed wywołaniem commit możliwa jest utrata historii dla tego pliku. Aby odtworzyć ten scenariusz należy zmienić nazwę pliku (git mv file1.txt file2.txt), po czym zmodyfikować go znacząco (echo DuzoDuzoNowychDanych > file2.txt), dodać nowy plik do repozytorium (git add file2.txt) i dokonać commit (git commit -m "zmiana"). Historia pliku i jego poprzednia nazwa przepadnie (git log --follow file2.txt). |
| Popularność tego rozwiązania maleje. | Popularność tego rozwiązania rośnie. |
Warto tu też obalić powszechny mit, że SVN i/lub Git narzucają system pracy. Narzucać mogą go narzędzie dodatkowe (np. BitBucket), ale nie sam system kontroli wersji. Zarówno SVN, jak i Git może mieć dowolne nazewnictwo branchy i organizację pracy na nich. Wykonywania zadania w danej firmie może wiązać się z dowolnymi, ustalonymi wewnętrznie etapami.
Kiedy używać którego?
🔹Chcę rozpocząć projekt lub kilka projektów programistycznych samodzielnie. Będę je wytwarzał we własnym zakresie i chcę używać narzędzi wersjonowania kodu.
W tym wypadku w pierwszej kolejności może warto rozpatrzeć jedno z lokalnych narzędzi do kontroli wersji zamiast całego repozytorium (czyli jeśli i tak nie będziemy udostępniać kodu). Jeśli jednak musimy zawężyć wybór do Git lub SVN to bardziej interesujący może być Git. Jeśli go nie znasz - nauczysz się jego obsługi i będzie to atut w pracy zawodowej. Repozytorium będzie można założyć na własnym komputerze bez udziału żadnego serwera. Można też użyć jednej z popularnych firm hostujących Git.
🔹Chcę rozpocząć projekt lub kilka projektów programistycznych samodzielnie. Będę je wytwarzał we własnym zakresie i chcę używać repozytorium na innym serwerze, aby dysponować w ten sposób kopią zapasową kodu w innej lokacji niż mój komputer. Posiadam w tym celu własny serwer w Internecie lub sieci lokalnej.
Tu należy odpowiedzieć sobie na pytanie jaki rodzaj pracy będziesz preferować i jakim serwerem dysponujesz. Jeśli będzie to serwer ustawiony w domu (np. NAS) i będziesz pracować także głównie w domu, to najpewniej najlepszym wyborem jest SVN. Zainstalujesz go szybko, nie zajmie on dużo zasobów, nie będziesz duplikować całego repozytorium na kilku swoich komputerach (szczególnie jeśli masz automatyczny backup i/lub dyski w RAID - repozytorium na NAS może być wystarczająco zabezpieczone, a ostateczną wersję kodu i tak będziesz przechowywać na komputerze roboczym jako dodatkową kopię).
Jeśli serwer jest tylko w sieci lokalnej, nie ma możliwości wystawienia portu na zewnętrznym IP, a praca będzie odbywać się często poza tą siecią, to lepszym rozwiązaniem okaże się Git. Będziesz mógł pracować w dowolnych lokacjach na swoim komputerze, wykonywać branche, commit itp. i od czasu do czasu synchronizować się z serwerem w celu posiadania kopii zapasowej.
Jeśli chcesz aby serwer był dostępny w Internecie i jest to możliwe, a ty możesz chcieć pracować z poziomu wielu komputerów na tym samym kodzie SVN może okazać się dla ciebie poręczniejszy. Twój serwer (VPS lub inny) z łatwością udźwignie Subversion obok innych usług. Będziesz mógł ściągać fragmenty repozytoriów na dowolny z komputerów i dokonywać poprawek lub podglądać kod, który będzie akurat ci potrzebny. Nie będziesz się obawiał, że pozostawisz przypadkiem całe swoje repozytorium na obcym komputerze (co najwyżej fragmenty kodu). Będziesz mógł ustawić uprawnienia dla każdego brancha/projektu/katalogu i przezornie np. używać użytkownika tylko-do-odczytu gdy nie będziesz do końca ufał komputerowi, na którym pracujesz. Każda z twoich maszyn nie będzie zbędnie duplikować całego repozytorium na swoim dysku.
🔹Mam w swojej firmie stary projekt, który jest nierozwijany, ale okazjonalnie wymaga pomniejszych poprawek. Aktualnie zlokalizowany jest na prywatnym serwerze SVN firmy. Czy ma sens migracja na Git?
Jeśli nie ma w firmie globalnego ruchu w celu migracji na jeden system kontroli wersji i możesz pozwolić sobie na wybór dowolnego dla każdego z projektów, pozostaw ten projekt na SVN. Migracja zajmie niepotrzebnie czas i zasoby, a nie będzie żadnego zysku dla takiego projektu niezależnie od stylu pracy w firmie.
🔹Prowadzę projekt open-source. Chcę aby ludzie byli zainteresowani moim oprogramowaniem i być może nawet kooperowali ze mną lub tworzyli jego forki.
Najprawdopodobniej powinieneś zainteresować się Git i firmą hostującą takie repozytorium (gotowe rozwiązanie).
🔹Rozpoczynam projekt razem z sześcioma osobami w firmie. Chcemy pracować w systemie osobnych branchy dla każdego zadania, wykonywać na nich przeglądy (review) i merge do głównego nurtu. Pracownicy pracują czasem z domu, a czasem z biura na służbowych laptopach.
Najprawdopodobniej będziecie woleć pracę z Git. Służbowy laptop nie musi posiadać dużo wolnego miejsca na dysku na rzeczy niezwiązane z wytwarzaniem kodu. Review i operowanie na branchach w Git jest bardziej klarowne. Pracownicy będą mogli kontynuować pracę nawet gdy w domu zerwie im połączenie z siecią w wyniku awarii dostawcy lub nawet gdy repozytorium samo w sobie nie będzie dostępne w Internecie (serwer w sieci wewnętrznej firmy).
🔹W projekcie będą uczestniczyć osoby nie mające wysokich umiejętności korzystania z trudniejszych narzędzi. Wszyscy oni będą dostępni w biurze firmy podczas pracy. Będą umieszczać np. tekstowe tłumaczenia, artykuły, dokumentację w repozytorium.
Dobrym wyborem może okazać się SVN. Posiada on narzędzia z dojrzałym i łatwym w użytkowaniu GUI. Będzie to znacznie przyjaźniejsze dla osób mniej zaawansowanych. Będzie to szczególnie dobry wybór jeśli ich część pracy musi być wydzielona od reszty (np. mają mieć uprawnienia tylko do katalogów projektu z dokumentacją i tekstami tłumaczeń), bo w SVN łatwo ustawić uprawnienia do fragmentów repozytorium i łatwo ściągnąć tylko takie interesujące nas fragmenty na dysk nie zawracając sobie głowy całą resztą.
🔹Chcę używać repozytorium z wersjonowaniem aby umieszczać w nim swoje kolekcje zdjęć i w ten sposób mieć kopię zapasową moich zdjęć wraz z historią obrabiania ich (poprzednie wersje plików).
Nie używaj do tego celu systemu kontroli wersji. Rozbij ten problem na dwa mniejsze: synchronizacja danych i ich wersjonowanie. Synchronizację z serwerem zapewni wiele darmowych narzędzi. Każda zmiana w katalogu ze zdjęciami może od razu propagować się na serwerze w ten sposób utrzymując aktualną kopię zapasową. Jednym z takich narzędzi jest darmowy program Syncthing. Problem wersjonowania rozwiążesz np. systemem plików po stronie serwera. Systemy plików takie jak ZFS czy BTRFS mogą dokonywać regularnych utrwaleń (snapshotów) poprzednich wersji katalogów i umożliwiają dowolne cofanie się w czasie aby oglądać poprzednie zmiany. Obsługują też deduplikację, więc kopie tego samego zdjęcia wrzucone do kilku katalogów zajmą miejsce na serwerze tylko raz.
Jeśli bardzo jednak upierasz się na SVN lub Git wybierz SVN do tego celu.
Jak widać różne scenariusze dają różne odpowiedzi. Warto więc spędzić chwilę aby zrozumieć cechy i różnice systemów kontroli wersji przed wprowadzeniem któregoś. Mam nadzieję, że ten artykuł będzie dla kogoś pomocny w przypadku takiego dylematu.