Git rozproszony system kontroli wersji Piotr Macuk Wstęp System kontroli wersji (ang. version control system, VCS) służy do śledzenia zmian projektu w czasie. Umożliwia współpracę wielu osób oraz ułatwia tworzenie i łączenie różnych gałęzi projektu. Najbardziej popularnym systemem VCS w świecie open source jest Subversion. Powstał on w celu zastąpienia wysłużonego CVS-a. Od kilku lat ma jednak silnego konkurenta, jakim jest Git. Projekt zainicjował Linus Torvalds, który potrzebował nowego systemu kontroli wersji do pracy nad rozwojem jądra Linuksa. W ekspresowym tempie powstał Git szybki i bardzo elastyczny systemem VCS. Historia Projekt jądra Linuksa jest bardzo dużym i złożonym przedsięwzięciem. Przez długi czas (1991-2002) zmiany w projekcie były realizowane bez pomocy systemu kontroli wersji. Nakładano łaty i tworzono migawki określonych wersji kodu. W 2002 roku zaczęto używać komercyjnego systemu BitKeeper. W tym przypadku jego używanie było bezpłatne. W kwietniu 2005 roku, w kontrowersyjny sposób, zmieniono zasady licencjonowania systemu BitKeeper dla projektu jądra Linuksa. Żaden z istniejących wtedy
30 Piotr Macuk systemów VCS nie spełniał oczekiwań twórców projektu. Linus poświęcił dwa tygodnie na próbę stworzenia nowego systemu kontroli wersji, który byłby odpowiedni. Zostały zdefiniowane następujące cele: szybkość działania, prostota konstrukcji, łatwość w tworzeniu oraz łączeniu gałęzi kodu, możliwość rozproszenia pracy, wydajność przy obsłudze dużych projektów. Próba Linusa pokazała, że jest to realne. W ciągu dwóch i pół miesiąca (3 kwietnia 16 czerwca 2005) powstał system, który produkcyjnie zaczął obsługiwać źródła jądra Linuksa. Podział systemów VCS Systemy kontroli wersji możemy podzielić na: lokalne, które działają tylko w obrębie jednego komputera (np. RCS), z centralnym repozytorium, które pozwalają na pracę w sieci i skupiają wszystkie zmiany w jednym miejscu (np. CVS, Subversion), rozproszone, które pozwalają na prace off-line oraz umożliwiają łatwą integrację zmian między repozytoriami (Git, Bazaar, Mercurial). Możemy zastosować też podział według sposobu przechowywania zmian w plikach. W systemach CVS, Subversion, Mercurial zmiany przechowywane są w postaci różnic między kolejnymi wersjami plików. Git i Bazaar przechowują kolejne wersje plików w całości Instalacja, konfiguracja, pomoc Najwygodniej zainstalować Git-a poprzez system pakietów dystrybucji Linuksa. Główny pakiet projektu nazywa się git-core. Konfiguracja ogranicza się do podania imienia, nazwiska i adresu e-mail użytkownika. $ git config --global user.name "Piotr Macuk" $ git config --global user.email piotr@macuk.pl Te informacje zapisywane są w pliku ~/.gitconfig i są globalne dla wszystkich repozytoriów danego użytkownika. Ogólna konfiguracja znajduje się w pliku /etc/gitconfig. Ustawienia konkretnego repozytorium są w pliku.git/config w katalogu z kopią roboczą projektu. Pomoc na temat poleceń Git-a uzyskamy wydając komendę
git help polecenie. Git rozproszony system kontroli wersji 31 Podstawowy cykl pracy Aby stworzyć repozytorium, wydajemy komendę git init w katalogu projektu. Tworzony jest podkatalog.git, w którym znajduje się repozytorium. Poleceniem git add wskazujemy pliki, które chcemy do niego dodać. Komenda git commit umieszcza je w repozytorium. Git jako jedyny system VCS posiada indeks, czyli miejsce, w którym przygotowujemy najbliższą Łoperacjięoperację git commit. Dzięki temu możemy zobaczyć jak zostanie zmodyfikowane repozytorium. Zmiany w pliku można dodawać do indeksu w całości (cały zmodyfikowany plik) lub w części (określona zmiana w wybranej części pliku). Podstawowy cykl pracy wygląda następująco: 1. Wykonujemy zmiany w projekcie. 2. Sprawdzamy je przy pomocy git status, git diff. 3. Dodajemy wybrane zmiany do indeksu (git add). 4. Sprawdzamy indeks przy pomocy git diff --cached. 5. Dodajemy zmiany do repozytorium (git commit). Można skrócić ten cykl do punktów 1 i 5. Komenda git commit -a może automatycznie dodać zmienione pliki do indeksu (punkt 3). Rozgałęzienia kodu Idea tworzenia i łączenia gałęzi kodu jest obecna we wszystkich nowoczesnych systemach kontroli wersji. Implementacja tej funkcji jest różna i bardzo wpływa na łatwość oraz szybkość jej używania. Konstrukcja Git-a wręcz zachęca do używania różnych gałęzi kodu. Jest to jedna z cech, które zdecydowały o popularności tego systemu kontroli wersji. Gałęzie głównie są wykorzystywane do równoległej pracy nad kilkoma wersjami projektu. Można je także tworzyć do pracy nad implementacją nowej funkcji lub do poprawienia wykrytego błędu. Do zarządzania gałęziami projektu służy polecenie git branch. Do aktualizacji gałęzi względem innej gałęzi służy polecenie git rebase. Łączenie zmian realizujemy przy pomocy polecenia git merge. Współpraca w grupie Git jest system rozproszonym. Każde repozytorium jest samowystarczalne i można z nim pracować lokalnie, równocześnie może stać się ono głównym repozytorim dla
32 Piotr Macuk danego projektu. Do współpracy z zewnętrznymi repozytoriami służą komendy git remote, git fetch, git pull oraz git push. Istnieje kilka sposobów wspólnej pracy nad projektem: 1. Pobieranie zmian z innego repozytorium. Wskazując repozytorium innej osoby możemy pobrać jej zmiany oraz wprowadzić je do naszego repozytorium. 2. Praca w modelu centralnym. Można skonfigurować Git-a jako system z centralnym repozytorium. Z takiego miejsca pobierane są aktualne wersje projektu. W lokalnych repozytoriach odbywa się praca nad zmianami, które później przekazywane są do centralnego repozytorium. Odpowiada to modelowi pracy z Subversion, z tą różnicą, że jedyną operacją sieciową jest pobranie aktualnej wersji projektu oraz przesłanie swoich zmian na serwer. Całą pracę (wiele operacji typu commit) można wykonać lokalnie. 3. Praca w modelu rozproszonym. W projekcie istnieje jedno główne repozytorium, które ma swojego opiekuna. Osoby pracujące nad poszczególnymi zmianami wysyłają mu prośby o pobranie swoich zmian (ang. pull requests). Opiekun pobiera wersje od poszczególnych osób i ma możliwość wprowadzenia ich do głównego repozytorium. Co jakiś czas osoby współpracujące aktualizują swoje repozytoria względem głównego. Dodatkowe narzędzia Istnieje sporo dodatkowych narzędzi pomocnych przy pracy z Git-em. Jednym z ważniejszych jest program gitk, który jest przeglądarką repozytorium. W czytelny sposób pokazuje on historię projektu oraz poszczególne gałęzie kodu. Umożliwia wykonywanie podstawowych operacji na gałęziach, tagowanie, wyświetlanie różnic między wersjami, itp. Konsolowym odpowiednikem gitk jest tig. Wydajność Git jest bardzo szybkim i wydajnym systemem VCS. Jego konstrukcja powoduje, że operacje przeglądania historii czy pokazywania różnic między wskazanymi wersjami kodu są wykonywanie błyskawicznie. Operacje git commit oraz tworzenie i łączenie gałęzi kodu są bardzo szybkie, ponieważ odbywają się lokalnie. Operacje sieciowe to jedynie pobranie aktualnej wersji projektu oraz publikacja własnych zmian w zdalnym repozytorium. Wysoka wydajność pracy Git-a jest okupiona nieco większym rozmiarem repozytorium.
Git rozproszony system kontroli wersji 33 Migracja do Git-a Dla większości systemów kontroli wersji istnieją narzędzia pozwalające na łatwą migrację projektu do Git-a. Na przykład prosta migracja z Subversion sprowadza się do wykonania następującego polecenia: $ git-svn clone http://host.pl/svn/my_project my_project Linki [1] YouTube: Linus Torvalds on git [2] http://whygitisbetterthanx.com [3] http://git-scm.com [4] http://gitcasts.com [5] http://progit.org [6] http://learn.github.com