Podstawy systemu kontroli wersji GIT

System kontroli wersji GIT stał się obecnie na tyle popularny i powszechnie używany, że jego znajomość wśród programistów jest jak znajomość HTML’a – nawet jak w tym momencie nie korzystasz na co dzień to wypada znać chociaż podstawy.

Sam też nie jestem osobą, która doskonale zna GITa jednak tyle co umiem wystarcza do standardowych zadań, a w razie problemów zawsze można zapytać Google. Tutaj napiszę tylko o bardzo podstawowych zagadnieniach, które pozwolą Ci dołączyć się do istniejącego projektu. Jak zazwyczaj w moich wpisach, bez nadmiaru teorii tylko sposób użycia, jeśli potrzebujesz więcej odsyłam do oficjalnego podręcznika i dokumentacji. Polecenia będę omawiał w kontekście używania ich z poziomu konsoli, jeśli w twoim IDE masz graficzne nakładki na GITa to do podstawowych zadań możesz z nich spokojnie korzystać, jednak warto wiedzieć jak poruszać się też wśród tekstowych poleceń bo z doświadczenia wiem, że czasami bez tego ani rusz (zwłaszcza kiedy coś się zepsuje :D ). Zakładam, że wiesz jak poruszać się w „linuksowy” sposób po katalogach, ponieważ nawet pod Windowsem konsola GITa obsługuje polecenia linuxowe takie jak cd czy mkdir.

Jeśli masz chwilę i chcesz poznać teorię i filozofię tego systemu to odsyłam do oficjalnego podręcznika: http://git-scm.com/book/en/Getting-Started . Jest on też gdzieś dostępny w wersji polskiej, ale opis jest na tyle prosty, że nie będę jeszcze bardziej ułatwiał sprawy ;)

1. Pobranie projektu

Żeby móc zacząć pracę nad projektem wypadałoby go najpierw zdobyć. Nie rozważam tutaj sytuacji kiedy sam zaczynasz nowy projekt i chcesz utworzyć repozytorium.

Pobranie projektu jest bardzo proste. Najpierw przejdź do katalogu gdzie chcesz ściągnąć repozytorium. Teraz wpisz poniższe polecenie:

git clone adres

 gdzie adres to adres do zdalnego repozytorium, który np. po prostu ktoś w pracy Ci poda.

Po zatwierdzeniu może jeszcze ewentualnie zapytać o hasło jeśli repo jest zabezpieczone i to tyle. Od tej pory masz w wybranym katalogu lokalną kopię repozytorium jako nowy folder o nazwie takiej jak projekt, gdzie znajdują się wszystkie jego pliki.

2. Dodawanie/edycja plików

Pliki możesz dodawać/edytować w projekcie tak jak zwykle, w edytorze, nie ma tutaj żadnych ograniczeń. Jednak kiedy wprowadzisz jakieś zmiany i chciałbyś je dodać do repozytorium to musisz wykonać następujące kroki. Najpierw w konsoli przejdź do katalogu projektu (ten, który został utworzony po pobraniu repozytorium). Teraz możesz sprawdzić jakie pliki uległy zmianie lub zostały dodane wpisując polecenie:

git status

Pojawi się lista zmienianych przez Ciebie plików.

Jeśli chcesz dodać do repozytorium wszystko co zmieniałeś wykonaj w głównym katalogu projektu:

git add .

Teraz po wykonaniu git status wszystkie pliki/katalogi jakie zostaną uwzględnione będą zaznaczone na zielono.

Gdybyś chciał wrzucić tylko niektóre zmienione pliki (np. kiedy chcesz pominąć to nad czym jeszcze nie skończyłeś pracować) to po prostu przejdź do wybranych podkatalogów i/lub w poleceniu git add podaj nazwy plików:

git add plik.cpp

Po poleceniu add pora zrobić commit (to słowo będziesz słyszał baardzo często pracując z GITem, tak jak jego czasownikową wariację – zcommitować). Prosty commit nie jest niczym skomplikowanym:

git commit -m "Krotki opis co zrobiles"

Opcja -m pozwala od razu podać krótki opis commita, jeśli trzymasz się zasady commitowania małych zmian to nie będziesz miał za często potrzeby rozpisywania się w tym miejscu.

Zrobienie commita spowoduje dodanie go w twojej lokalnej kopii repozytorium, tzn. na razie jeszcze nikt inny go nie zobaczy.

3. Wysyłanie zmian do zdalnego repozytorium

Jeśli już zrobiłeś jeden lub więcej lokalnych commitów to możesz, a nawet powinieneś je wysłać do zdalnego repozytorium tak żeby reszta zespołu mogła je pobrać.

Jednak jest ważna zasada przy wrzucaniu czegokolwiek do zdalnego repozytorium: zanim to zrobisz najpierw pobierz najaktualniejsze zmiany! Służy do tego polecenie:

git pull

Dzięki temu będziesz pewien, że to co zrobiłeś nie koliduje ze zmianami wprowadzonymi przez resztę zespołu (np. kiedy edytowaliście ten sam plik, co raczej nie powinno się zdarzyć). W razie konfliktów należy ręcznie je rozwiązać, ale tego procesu nie będę tutaj opisywał, odsyłam jedynie do oficjalnej dokumentacji lub do Google.

Polecenie pull używaj częściej niż raz dziennie, albo co gorsza raz w tygodniu ;) Dzięki temu będziesz pracował na aktualnych plikach co ułatwi pracę ogółu bo nie będziesz marudził, że coś nie działa albo czegoś brakuje. To samo tyczy się wrzucania zrobionych przez Ciebie zmian. Jeśli będziesz to robił wystarczająco często, tzn. przynajmniej raz dziennie pod koniec dnia to unikniesz bycia winowajcą bałaganu i miliona konfliktów w projekcie.

No dobra, to jak wypchnąć zmiany „na zewnątrz”? Nie bez powodu użyłem słowa „wypchnąć” ponieważ do tego celu służy polecenie:

git push

Może ono, tak jak clone lub pull wymagać podania hasła jeśli repozytorium jest zabezpieczone. Po jego wykonaniu, jeśli niczego nie popsułeś, zmiany przez Ciebie wprowadzone będą dostępne dla reszty zespołu, kiedy zrobią oni pusha.

Podsumowanie

Przed chwilą pokazałem Ci najbardziej podstawowe z podstawowych poleceń potrzebnych do pracy z repozytorium GITa. Dzięki temu będziesz przynajmniej wiedział jak wygląda codzienna praca z nim i mam nadzieję spróbujesz go użyć nawet w swoich prywatnych projektach. Brakuje tutaj opisu jak pracować np. z branchami (gałęziami), które są bardzo dobre żeby móc oddzielić kod produkcyjny od deweloperskiego, albo żeby móc pracować na kilku wersjach projektu jednocześnie. Jednak ten temat jak i inne wymagały by szerszego opisu, poza tym są, moim zdaniem, bardzo dobrze opisane w oficjalnym podręczniku, do którego polecam sięgnąć zaraz po przeczytaniu tego posta.

Linki

Oficjalny podręcznik GITa (en)

Darmowe, publiczne serwery repozytoriów GITa, na których możesz trzymać zdalnie swoje projekty:
GitHub
BitBucket (pozwala też tworzyć repozytoria prywatne)