Dzisiejszy wpis będzie wprowadzeniem i jednocześnie krótkim tutorialem na temat GITa. Do tej pory przy swoich projektach nie korzystałem z systemów kontroli wersji, a w pracy działaliśmy na Perforce, który jest dużym i wolnym narzędziem. Sprawdza się w korporacjach, natomiast jeśli chodzi o własne produkcje, to przydałoby się coś małego, szybkiego i prostego w obsłudze. Czy jest coś takiego? Oczywiście, z pomocą przychodzi system kontroli wersji o nazwie GIT.

Seria: GIT i GitHub

Ten wpis jest pierwszym z trzech na temat GITa jako takiego, serwisu społecznościowego GitHub oraz instalacji i zarządzania projektami na własnym serwerze. Poniżej znajdą się linki do wszystkich trzech wpisów, w miarę ich pojawiania się na blogu:

1 z 3 | GIT tutorial (GIT - łatwy system kontroli wersji)
2 z 3 | Serwis GitHub (GitHub - kodowanie społecznościowe)
3 z 3 | GIT na serwerze


Czym jest GIT?

GIT to rozproszony system kontroli wersji, jego autorem jest Linus Torvalds, twórca Linuksa. GIT jest oprogramowaniem open source na licencji GNU GPL. Torvalds potrzebując dobrego i szybkiego rozproszonego systemu kontroli wersji szukał gotowych rozwiązań, jednak żadne go nie satysfakcjonowało, więc postanowił napisać własne, co miało miejsce w 2005 roku. Wiele dużych projektów korzysta z GITa jako systemu kontroli wersji: Android, Digg, GIMP, jQuery, Linux, phpMyAdmin czy Symfony.

Instalacja GITa

Zainstalowanie GITa na swoim komputerze jest bardzo proste. Wystarczy ściągnąć instalator (dla MAC OS X lub Windows), po lewej stronie w dziale Downloads znajdują się najnowsze paczki. Uruchomienie także nie powinno przysparzać zbyt wielu problemów - na Mac OS X wystarczy odpalić Terminal, natomiast na Windows uruchomić Git Bash. Wszystkie polecenia będziemy wykonywać z poziomu linii komend.

Konfiguracja wstępna

Nie jest to niezbędne, jednak warto odpowiednio przygotować GITa do pracy. W konsolę wpisujemy po kolei poniższe polecenia:
git config --global user.name "Imię i nazwisko"
git config --global user.email "adres@email.pl"
git config --global color.status auto
git config --global color.branch auto

Oczywiście wpisując swoje imię i nazwisko oraz poprawny adres e-mail - dzięki temu każdy commit do projektów będzie odpowiednio podpisany. Kolejne dwie linijki udostępniają kolorowanie tekstu w konsoli, co ułatwia jego czytanie.

GIT init

Ok, konfiguracja wstępna za nami, zajmijmy się przykładowym projektem: nazwijmy go po prostu pierwszyProjekt. Skorzystajmy z linii poleceń (Terminal dla Mac i Git Bash dla Windows), by stworzyć na naszym dysku folder o takiej nazwie, wejść do niego, po czym używając git init zainicjalizować puste repozytorium. Dzięki temu zostanie stworzony ukryty folder o nazwie .git, zawierający całą historię zmian naszego projektu.
screen 1

GIT add

Załóżmy, że zaczęliśmy już pracę nad naszym projektem, a więc zawiera on już jakieś pliki - przydałoby się zapisać w historii GITa ich aktualną zawartość. Użyjemy polecenia git add, które dodaje zmienione pliki do wirtualnej listy, którą za chwilę zapiszemy używając polecenia commit. Możemy od razu dodać wszystkie zmienione pliki do listy używając kropki:
git add .

lub wypisać konkretne pliki:
git add index.php
git add style.css

GIT commit

Tym poleceniem zapiszemy aktualny stan naszego projektu. Warto przy każdym użyciu commit dodawać także komentarz opisujący zmiany, które wprowadziliśmy w naszym projekcie. Jak to zrobić? Wystarczy w linii poleceń wpisać:
git commit -m "tu wpisz komentarz"

Jeśli chcesz usprawnić sobie pracę z GITem, możesz użyć dodatkowego parametru -a, który zadziała jak git add ., dzięki czemu będzie można jednym poleceniem dodać zmienione pliki do naszej listy i zapisać ich aktualny stan. Pamiętaj, że to polecenie nie doda nowych plików, jedynie te zmodyfikowane:
git commit -am "tu wpisz komentarz"

Oto jak wygląda konsola po użyciu powyższego polecenia na naszym projekcie:
screen 2
Gratulacje, właśnie nauczyłeś się zapisywać zmiany w projekcie przy użyciu GITa, prostego systemu kontroli wersji! Zobaczmy jakie jeszcze polecenia mogą nam się przydać podczas pracy z naszym projektem.

GIT status

To polecenie wyświetli aktualny status pracy nad projektem. Dzięki niemu zobaczysz które pliki były modyfikowane, ale nie zostały jeszcze zapisane poleceniem commit. Jeśli nie masz nic nowego, dostaniesz komunikat nothing to commit (working directory clean). Jeśli natomiast pliki ulegną zmianie od poprzedniego użycia commit, zostanie wyświetlone odpowiednie podsumowanie:
screen 3
Zostało ono podzielone na dwie sekcje: "changes not staged for commit" oraz "untracked files". Pierwsza to pliki zmienione, ale nie zapisane na liście do dodania w repozytorium GITa. Druga to lista plików, których nie ma jeszcze w ogóle w repozytorium, a więc są to nowe pliki. Po użyciu polecenia git add zobaczymy sekcję "changes to be committed", a więc listę plików gotowych do zapisania w repozytorium poleceniem commit.
screen 4

GIT branch

Do czego służy git branch? Czym w ogóle jest branch? W naszym projekcie jest to dział, sekcja, gałąź kodu. Nadal znajdujemy się w obrębie jednego projektu, ale możemy rozdzilić go na dwie gałęzie. Po co obić coś takiego? Załóżmy, że wpadliśmy na świetny pomysł, ale może on znacznie zmodyfikować nasz kod. Dodatkowo, jeśli oprócz nas nad projektem pracuje jeszcze ktoś, możemy popsuć mu jego zmiany. Idealnym wyjściem jest rozdzielenie kodu, stworzenie nowej gałęzi, na której będziemy rozwijać nasz wspaniały pomysł. Pamiętajmy, że domyślnie nasz projekt ma zdefiniowany branch o nazwie master. Używając polecenia git branch superPomysl tworzymy nową gałąź kodu o nazwie superPomysl. Nadal jednak aktywną gałęzią jest master, jak przejść na nowo utworzony superPomysl? Z pomocą przychodzi nam kolejne polecenie...

GIT checkout

Dzięki checkout możemy przełączać się pomiędzy różnymi gałęziami kodu w naszym projekcie (utworzonymi za pomocą polecenia branch). Wykonując polecenie git checkout superPomysl przełączymy się z domyślnej gałęzi na tą, która nas teraz interesuje. Zobaczmy teraz oba wspomniane polecenia w akcji:
screen 5

GIT merge

Załóżmy, że zdążyliśmy już popracować nad naszym super pomysłem, który okazał się być bardzo przydatnym, a co najważniejsze działającym elementem. Działamy na nim jak na zwykłej gałęzi, czyli dodajemy pliki używając git add oraz zapisując je przy pomocy git commit. Chcielibyśmy wrócić do naszej pierwotnej gałęzi master, ale ze zmianami wprowadzonymi w gałęzi superPomysł. Z pomocą przychodzi nam polecenie git merge, które łączy dwie gałęzie rozwiązując proste konflikty. Zobaczmy, jak to wygląda w praktyce:
screen 6
Jak widać użyliśmy polecenia git branch z argumentem -d, który umożliwia usunięcie niepotrzebnej już, pustej gałęzi kodu.

GIT log

To polecenie służy nam do przejrzenia historii zmian dokonanych w projekcie. Na liście wypisane są szczegółowe informacje odnośnie poszczególnych etapów, gałęzi, modyfikacji plików. Tutaj możemy sprawdzić jak rozwijał się nasz projekt.
screen 7

GITK

Polecenie git log jest przydatne, jednak przy większych projektach przeglądanie logów może być mało wygodne. Do dyspozycji dostajemy więc narzędzie, dzięki któremu będziemy mieli pełną kontrolę nad naszym projektem, będziemy mogli przeglądać historię, oglądać poszczególne zmiany, gałęzie, porównywać poszczególne etapy.
screen 8

Materiały dodatkowe

Po więcej informacji odsyłam do serwisu GitRef.org, webcasta O'Reilly "Git in one hour", a także świetnej, darmowej książki Pro Git.

Podsumowanie

Należy pamiętać, że jest to jedynie wstęp, przedstawienie podstaw GITa. Warto zapoznać się z zaawansowanymi funkcjami GITa, dzięki czemu wydobędziemyz tego narzędzia pełną moc w naszych projektach. W kolejnym wpisie z tej serii napiszę o społecznościowym podejściu do systemu kontroli wersji i jednoczesnym dzieleniu się kodem ze wszystkimi zainteresowanymi, a więc będzie o serwisie GitHub.