W ramach odstresowania się od sesji, krótki tutorial używania gita. :) Czym jest git można sprawdzić tutaj, dlaczego warto go używać, można poczytać tutaj lub posłuchać tutaj (tak, przesłuchałem to X razy i jakoś wyszło podobnie, sio marudy :P). A dzisiaj kilka podstawowych poleceń jak używać gita (jeżeli następnym razem napiszę o gitcie będzie to porównanie szybkości między gitem, hg, bazarem i svnem, z kolorowymi wykresami! Można obstawiać wyniki, a zwycięzca dostanie nagrodę niespodziankę).

Pierwsze co musimy wiedzieć to format poleceń gita:

git add plik

Czyli czym (gitem), co i na końcu komu. Była jeszcze wersja z łączeniem poleceń myślnikiem:

git-add plik

Ale (przynajmniej u mnie) już ona nie występuje. Druga ważna rzecz, to konfiguracja gita. Git do każdego commita dodaje dane osoby, która go zrobiła, więc należy mu je najpierw podać zanim cokolwiek zaczniemy robić:

git config --global user.name "Mateusz Marek"
git config --global user.email matthew@matthew.org.pl

Myślę, że to nie wymaga tłumaczenia, więc teraz przejdziemy do zabawy. Wchodzimy do katalogu, który chcemy objąć kontrolą wersji i wydajemy takie oto polecenia:

git init
git add .
git commit -m "komentarz"

Pierwsze polecenie zakłada nam lokalne repozytorium w naszym katalogu. Drugie dodaje wszystkie pliki z bieżącego katalogu do indeksu, natomiast ostanie bierze nasze pliki z indeksu i włącza je do repozytorium (parametr „m” odpowiada za dodanie komentarza do commitu). Teraz możemy sobie napchać do katalogu kolejne pliki, edytować istniejące i lecimy z gitem:

git add plik.c

git commit -a -m "komentarz"

Dodajemy „plik.c” oraz commitujemy całość do repozytorium. Brak parametru „a” spowodowałby dodanie do repo tylko pliku „plik.c”. Parametr „a” mówi gitowi o automatycznym dodaniu wszystkich plików, które zostały zmodyfikowane lub usunięte (dzięki temu nie musimy ponownie wydawać polecenia „add” dla każdego z nich). Jeżeli teraz chcielibyśmy umieścić nasz kod gdzieś na zewnątrz wydajemy polecenie (tak będzie wyglądało w przypadku GitHuba:

git push git@github.com:login/projekt.git master

Oczywiście adres nie jest najprzyjemniejszy do zapamiętania, więc możemy go sobie skrócić w ten sposób:

git remote add origin git@github.com:login/projekt.git

Origin jest ogólnie przyjętą nazwą dla głównego zdalnego repozytorium. Tak samo jak master jest ogólnie przyjętą nazwą dla głównej gałęzi w dowolnym repo. Jednak co nam po repozytorium które umieściliśmy na serwerze? Trzeba je jeszcze pobrać, a robi się to tak:

git clone git://github.com/login/projekt.git

I dostajemy katalog z naszą lokalna kopią repozytorium. Warto jednak by go od czasu do czasu aktualizować. Robimy to poprzez polecenie pull:

git pull git://github.com/login/projekt.git

Jednak ściąga ono i łączy repozytorium zdalne z naszą lokalną gałęzią bez pytania. Rozwiązaniem tego problemu jest używanie kombinacji fetch + merge:

git fetch origin/master
git merge origin/master

Pierwszym poleceniem pobieramy główną gałąź zdalnego repozytorium do „zdalnej”, głównej gałęzi, a drugim łączymy je z gałęzią w której aktualnie się znajdujemy (czyli w master). Po drodze możemy również sprawdzić różnice między obiema gałęziami:

git diff master origin/master

Na razie to tyle, jeżeli będzie zainteresowanie tym tutorialem to następnym razem opowiem o gałęziach w gitcie. Do zobaczenia, wracam do nauki. :)

Wiadomość źródłowa na blogu autora: git tutorial – część 1 – wstęp
Skład i korekta: mars3n

W ramach odstresowania się od sesji, krótki tutorial używania gita. :) Czym jest git można sprawdzić tutaj, dlaczego warto go używać, można poczytać tutaj lub posłuchać tutaj (tak, przesłuchałem to...