System kontroli wersji

GIT cz. I – Wstęp

By on 9 stycznia 2017

Obecnie w większości firm programiści spotykają się z problemem jak współdzielić kod z innymi programistami w taki sposób, aby nawzajem sobie nie przeszkadzać. Rozwiązaniem są systemy kontroli wersji. W chwili pisania tego artykułu najpopularniejszym takim systemem jest GIT. System ten nie tylko ułatwia współdzielić projekt, ale również dokumentuje poczynania współtwórców, kto, kiedy i jaki kod wstawił/usunął. Pozwala podejrzeć zmiany i przywrócić starsze wersje kodu. Zepsucie projektu przez początkującego użytkownika korzystając z systemu kontroli wersji jest trudne. Niemal zawsze starszy stażem programista może odkręcić to co zostało zepsute przywracając projekt do dawnego stanu.

Sama idea GIT opiera się na podziale na cztery obszary. Pierwszy obszar jest to katalog roboczy (working directory), czyli katalog w którym trzyma się pliki projektu i na nich pracuje. Drugi obszar to poczekalnia (staging area). Tymczasowo wrzuca się do niej zmodyfikowane pliki, które chcemy wysłać do repozytorium lokalnego. Do repozytorium lokalnego dodajemy wszystkie pliki będące w danym momencie w poczekalni przypisując im odpowiedni komentarz zmian. Automatyczne dodawane są także informacje o autorze zmian. Ostatni obszar to repozytorium zdalne, gdy wyślemy tam swój kod z repozytorium lokalnego to jest on dostępny dla wszystkich współtwórców projektu.

Uważam że najłatwiej zrozumieć to na uproszczonym przykładzie. Załóżmy że naszym zadaniem jest stworzenie tłumaczenia projektu na język hiszpański. Pierwszym etapem jest aktualizacja naszego projektu do obecnej wersji na podstawie repozytorium zdalnego, bo któryś ze współtwórców mógł wprowadzić jakieś zmiany, których jeszcze nie mamy u siebie. Kiedy mamy już na pewno aktualny projekt w katalogu roboczym, modyfikujemy wszystkie pliki odpowiadające za tłumaczenie i wszystkie te zmodyfikowane pliki dodajemy do poczekalni. Kiedy będziemy mieli w poczekalni już cały zestaw przetłumaczonych plików to robimy tzw. commit. Commit to zatwierdzenie zmian wszystkich plików z poczekalni i przesłanie ich do repozytorium lokalnego wraz z zwięzłym komentarzem do zmian np. „Spanish translation”. Ważne żeby komentarz dobrze opisywał czego dotyczyły zmiany i dotyczył wszystkich plików znajdujących się w poczekalni. Za normę przyjęło się też stosowanie języka angielskiego. Należy pamiętać też, aby robić commity z odpowiednią częstotliwością, nie za często, aby nie zaśmiecać historii komentarzem, co 2-3 nowe linie kodu oraz nie za rzadko, aby komentarze commitów tworzyły sensowną historię. Repozytorium lokalne jak nazwa wskazuje istnieje lokalnie na komputerze użytkownika, a nie w sieci. Znajduje się w domyślnie ukrytym podkatalogu .git katalogu roboczego. Zawiera ono informacje o wszystkich dotychczasowych commitach. Wydając odpowiednie polecenia w każdej chwili z repozytorium lokalnego jesteśmy w stanie przywrócić stan plików z dowolnego commita. W tym momencie pozostali współtwórcy projektu nie widzą nadal naszego tłumaczenia. W tym celu należy wypchnąć (push) je z repozytorium lokalnego do repozytorium zdalnego skąd pozostali będą mogli je pobrać i zaktualizować swoje wersje projektu. Warto wspomnieć że każda transmisja sieciowa w GIT jest szyfrowana, co zabezpiecza nasz projekt przed wpadnięciem w niepowołane ręce. Za repozytorium zdalne mogą służyć specjalne serwisy takie jak github.com, bitbucket.org, gitlab.com, jak i serwer postawiony przez firmę.

Był to krótki wstęp do systemu kontroli wersji GIT. W kolejnych częściach przejdziemy do praktyki.

TAGS

LEAVE A COMMENT