1. Czym jest system kontroli wersji
Za Wikipedią:"System kontroli wersji (ang. version/revision control system) – oprogramowanie służące do śledzenia zmian głównie w kodzie źródłowym oraz pomocy programistom w łączeniu zmian dokonanych w plikach przez wiele osób w różnych momentach czasowych."Do czego takie cuś się przydajeNiezależnie od tego, czy używa się go dla samego siebie, czy dla grupy osób, pozwala on na takie rzeczy, jak śledzenie zmian na plikach, czy w kodzie dokonanych w czasie przez jedną lub więcej osób. Co za tym idzie, porównywać te zmiany, łatwo prześledzić, które zmiany wpłynęły na co, kto dokonał tychże zmian (jak coś zepsuto, to wiadomo kogo stłuc), przywrócić pliki do wcześniejszego, dowolnie wybranego stanu (gdy coś się zepsuło, utracono jakieś pliki lub stwierdziliśmy, że dana droga prowadzi donikąd).Jak działa system kontroli wersjiPodchodząc do sprawy od strony laika można powiedzieć, że najprostszy model kontroli wersji stosowany jest również przez osoby, nie mające o tym zielonego pojęcia, na zasadzie działania czysto intuicyjnego. Kiedy przed stworzeniem obrazu wykonujesz kilka szkiców, a przed wyborem ścieżki w grze RPG klikasz na "save" żeby móc zmienić tą decyzję gdy okaże się, że to jednak nie to co chciałeś, można powiedzieć, że również stosujesz swego rodzaju system kontroli wersji na poziomie basic. Informatycy stworzyli zaawansowane systemy kontroli wersji, aby ułatwić nam życie - dzięki nim, nie musimy pamiętać o tym, by regularnie robić zapisy kolejnych wersji, przechowywać je w kilku miejscach, czy prowadzić dochodzenie mające na celu stwierdzić, kto dokonał jakich zmian we współdzielonych plikach.
2.Rodzaje systemów kontroli wersji
Możemy wyodrębnić trzy rodzaje systemów kontroli wersji: lokalne, scentralizowane i rozproszone.
1. Lokalne systemy kontroli wersji (VCS)
Składają się one z prostej (i oczywiście lokalnej) bazy danych, w której przechowywane są wszystkie zmiany dokonane na śledzonych plikach. Jednym z najpopularniejszych i niekiedy wciąż używanym VCS jest rcs. Służy on jednak do kontrolowania pojedynczych plików i nie nadaje się do śledzenia zmian dokonanych w całych projektach.
2. Scentralizowane systemy kontroli wersji (CVCS)
Powstały jako odpowiedź na zapotrzebowanie kontroli nad plikami, do których dostęp jest możliwy z różnych systemów/ urządzeń. Realizowane są one w architekturze klient-serwer, przy czym serwer jest jeden, a klientów może być wielu. Takie systemy nie tylko dają możliwość współpracy większej ilości osób nad danym zbiorem plików, ale również są łatwiejsze w zarządzaniu niż systemy lokalne. Problematyczne jest tutaj jednak oparcie systemu na tylko jednym serwerze - w przypadku jego awarii, niemożliwa będzie praca na udostępnianych plikach. Kolejny problem to dostęp jedynie do najnowszej wersji śledzonych plików.
Najpopularniejszymi systemami z tej rodziny są: CVS (Concurrent Versions System), jego następca Subversion, czy komercyjny Perforce.
3. Rozproszone systemy kontroli wersji (DVCS)
To z założenia ulepszona wersja CVCS. Mamy tutaj do czynienia z architekturą P2P. W przeciwieństwie do CVCS klienci mają dostęp nie tylko do najnowszej wersji plików - repozytorium zostaje w pełni skopiowane na każdego hosta. Dzięki temu, w przypadku awarii prowadzącej do utraty danych na jednym z serwerów, skopiowane repozytorium może posłużyć do ich przywrócenia. Przykładami DVCS są: wspomniany już wcześniej BitKeeper, Git, Mercurial, Bazaar czy Darcs
2.Rodzaje systemów kontroli wersji
Możemy wyodrębnić trzy rodzaje systemów kontroli wersji: lokalne, scentralizowane i rozproszone.
1. Lokalne systemy kontroli wersji (VCS)
Składają się one z prostej (i oczywiście lokalnej) bazy danych, w której przechowywane są wszystkie zmiany dokonane na śledzonych plikach. Jednym z najpopularniejszych i niekiedy wciąż używanym VCS jest rcs. Służy on jednak do kontrolowania pojedynczych plików i nie nadaje się do śledzenia zmian dokonanych w całych projektach.
2. Scentralizowane systemy kontroli wersji (CVCS)
Powstały jako odpowiedź na zapotrzebowanie kontroli nad plikami, do których dostęp jest możliwy z różnych systemów/ urządzeń. Realizowane są one w architekturze klient-serwer, przy czym serwer jest jeden, a klientów może być wielu. Takie systemy nie tylko dają możliwość współpracy większej ilości osób nad danym zbiorem plików, ale również są łatwiejsze w zarządzaniu niż systemy lokalne. Problematyczne jest tutaj jednak oparcie systemu na tylko jednym serwerze - w przypadku jego awarii, niemożliwa będzie praca na udostępnianych plikach. Kolejny problem to dostęp jedynie do najnowszej wersji śledzonych plików.
Najpopularniejszymi systemami z tej rodziny są: CVS (Concurrent Versions System), jego następca Subversion, czy komercyjny Perforce.
3. Rozproszone systemy kontroli wersji (DVCS)
To z założenia ulepszona wersja CVCS. Mamy tutaj do czynienia z architekturą P2P. W przeciwieństwie do CVCS klienci mają dostęp nie tylko do najnowszej wersji plików - repozytorium zostaje w pełni skopiowane na każdego hosta. Dzięki temu, w przypadku awarii prowadzącej do utraty danych na jednym z serwerów, skopiowane repozytorium może posłużyć do ich przywrócenia. Przykładami DVCS są: wspomniany już wcześniej BitKeeper, Git, Mercurial, Bazaar czy Darcs
3.Git
Nieco historii
Powstanie Git zawdzięczamy developerom jądra Linuxa, będącego rozwijanym przez programistów z całego świata i dystrybuowanym na licencji Open Source. Twórcy ci korzystali początkowo z innego oprogramowania służącego do kontroli wersji nazwanego BitKeeper stworzonego przez firmę BitMover. Od 2005 roku firma zrezygnowała z dystrybucji darmowej wersji swojego oprogramowania dla projektów o otwartym kodzie. I to był koniec współpracy z Linuksiarzami, a także początek Git. Celem twórców Git było stworzenie szybkiego, darmowego oraz prostego w obsłudze systemu kontroli wersji umożliwiającego efektywną pracę dużym grupom programistów jednocześnie i umożliwiającego sprawowanie pieczy nad projektami dużych rozmiarów.
Czym jest Git
Jak wspomniałam wyżej, Git jest rozproszonym systemem kontroli wersji. To co odróżnia go od innych, to przede wszystkim podejście do przechowywania danych - zamiast listy zmian na plikach, Git "sprawdza" stan wszystkich plików w danym repozytorium oraz tworzy referencję do tego stanu (tzw. snapshot lub migawka). Jeżeli jakiś plik w repozytorium pozostał niezmieniony, system nie "przepisuje" go na nowo, ale w danej migawce również odwołuje się do niego za pomocą referencji do jego poprzedniej wersji.
Ważną zaletą Git jest to, że do wykonania większości operacji wystarczy nam dostęp jedynie do lokalnych plików i zasobów. To oznacza nie tylko szybsze działanie, ale również możliwość pracy bez połączenia z serwerem.
Kolejnym punktem, o którym warto wspomnieć, jest wbudowany mechanizm spójności danych. O tym , jak to działa, przeczytać można tutaj.
Stany plików w Git
Pliki, nad którymi pracujemy z pomocą Git, znajdować się mogą w trzech stanach: zatwierdzony (comitted), zmodyfikowany (modified) oraz śledzony (staged). Poniższy obrazek pokazuje jak ma się to do trzech głównych sekcji projektu:
To tyle, jeśli chodzi o wprowadzenie do samego tematu jakim jest system kontroli wersji oraz Git. W celu zapoznania się ze szczegółami, polecam zapoznać się z książką Pro Git dostępną w całości tutaj (istnieje również polska wersja, odnosi się ona jednak do wcześniejszej wersji książki. Do odnalezienia tutaj).
Dla tych, którzy ciekawi są czym tak naprawdę różni się Git od swoich konkurentów, polecam następujące wpisy:
- Git vs Mercurial -> wpis na blogu z punktu widzenia doświadczonego użytkownika obu z nich
- Dlaczego Bazaar jest lepszy niż Git...
- a dlaczego Git jest lepszy niż Bazaar
- Spore porównanie Git, Mercurial i Bazaar w jednym
- Dlaczego Git ssie i Darcs jest fajniejszy
Wpisy te są z różnych lat i zapewne w każdym z systemów zmienione zostało wiele z wymienianych właściwości. Moim zdaniem dobrze jest jednak mieć świadomość tego, jak różni ludzie podchodzą do tej sprawy i co w danym rozwiązaniu jest dla nich najważniejsze
Brak komentarzy:
Prześlij komentarz