Zeyomir's Blog Bo piękniej jest wiedzieć coś o wszystkim…

6Paź/10Off
» «

Szybki start z gitem

Każdy programista powinien korzystać z systemu kontroli wersji i trzymać w nim swój kod. Kropka. Trzeba tylko któryś wybrać, a potem nauczyć się z niego korzystać ;). Wybór jest całkiem spory (CVS, SVN, SourceSafe, Mercurial, Git i ogrom takich które pominąłem lub o których nawet nie wiem), ale nie zamierzam się nad tym rozwodzić. Przyjmijmy zasadę "ja używam GITa i Ty też powinieneś" ;).

Instalacja

Zanim zaczniemy się bawić, wypadałoby zainstalować i skonfigurować gita. Instalacja jak zwykle nie przysporzy nam żadnych problemów- pod Linuksem instalujemy odpowiednią paczkę (polecam również doinstalować opcjonalną zależność- pakiet Tcl/Tk). Pod Windowsem instalujemy Git for Windows.
W zasadzie moglibyśmy już zacząć pracę, ale wysoce wskazane jest... przedstawienie się ;). W terminalu (pod Windowsem odpalamy 'git bash') wydajemy polecenia:

git config --global user.name "Jan Kowalski"
git config --global user.email jkowal@foo.bar

Te dane będą wykorzystywane do ustalenia autora commitu.

Pierwsze kroki

Tworzymy katalog dla naszego projektu, a w nim wykonujemy git init, co tworzy nam repozytorium w tym katalogu. Tworzymy kilka plików:

touch readme plik1.foo plik2.foo config.bar

Wydajemy polecenie git commit i... git informuje nas, że nie ma czego dorzucić do repozytorium, ale za to są jakieś pliki których on nie śledzi. No cóż- sam fakt, że plik jest w katalogu nie oznacza jeszcze, że git powinien się interesować jego zmianami. Nakazujemy śledzenie zmian (dodanie do repozytorium) poprzez polecenie git add config.bar *.foo.

Odpalamy teraz git commit, trzymamy kciuki i... widzimy edytor tekstu (vim) z zakomentowanymi informacjami na temat commitu. Powinniśmy teraz sporządzić jego krótki opis. Zalecenie brzmi: pierwsza linijka to 'tytuł', potem linijka odstępu i szerszy opis. Zamykamy edytor i hurra- nasz pierwszy commit zostaje wysłany :).

Dorzucamy coś do któregoś z plików i próbujemy wysłać kolejny commit. Tu niespodzianka- git mówi 'coś się zmieniło w plikach które śledzę, ale nie wiem czy mam te zmiany uwzględnić'. Żeby to potwierdzić, musimy ponownie dodać te zmienione pliki poleceniem git add nazwy_plikow. Oczywiście jest to dość męczące, żeby za każdym razem wpisywać nazwy plików- istnieją więc 2 skróty. Po pierwsze możemy wykonać git commit -a, co spowoduje zacommitowanie wszystkich zmienionych plików, które są śledzone. Po drugie możemy użyć git add ., co spowoduje dodanie wszystkich plików w folderze (UWAGA- dodaje również nieśledzone pliki, które od tej pory stają się śledzone!), a następnie zacommitować je tak jak przy pierwszym commicie.

Drugie kroki 😉

Jeżeli nie chcemy żeby jakieś pliki kiedykolwiek zostały dodane do śledzenia (nawet pomimo użycia git add .), musimy je wpisać do pliku .gitignore w głównym katalogu. Przydaje się to chociażby do pomijania plików wygenerowanych podczas kompilacji. By usunąć jakiś plik z repozytorium (przestać go śledzić) nie wystarczy samo usunięcie pliku w folderze- należy wywołać komendę git rm nazwa_pliku. Zmiana nazwy pliku odbywa się przy pomocy polecenia git mv nazwa_pliku nowa_nazwa_pliku.

Żeby podejrzeć które pliki zmienialiśmy i które z nich dodaliśmy już do commita którego zaraz wyślemy, możemy użyć git status. Żeby zobaczyć co dokładnie zmieniliśmy w tych plikach, używamy git diff. Historię commitów możemy podejrzeć dzięki git log, a dodatkowo możemy ją zaprezentować w postaci grafu git log --graph. Względnie możemy wyświetlić dane graficznie- pod Linuksem musimy mieć zainstalowany pakiet Tcl/Tk i wydać polecenie gitk, pod Windowsem możemy postąpić tak samo lub kliknąć PPM w folderze z repozytorium i wybrać 'Git History' (sporą część operacji, jeśli nie wszystkie, można pod Windowsem wyklikać korzystając z menu kontekstowego, 'git gui' itd- nie piszę o nich jednak, ponieważ i tak szybciej jest wklepać co trzeba w konsolę 😉 ).

Jeżeli już wysłaliśmy commita i nagle okazało się, że zapomnieliśmy o jakimś pliku albo nie dopisaliśmy czegoś w opisie- bez paniki ;). Dzięki git commit --amend możemy nadpisać ostatni commit. Podróż w czasie (przywracanie stanu z przeszłości) możliwa jest na 2 sposoby. git reset HEAD pozwala nam się przenieść do konkretnego commitu, pozostawiając naszą pracę (zmiany w plikach) tak jak były- czyli w stanie z teraźniejszości. git checkout HEAD przenosi nas do danego commitu, nadpisując pliki w folderze stanem z tego commitu- jest to więc polecenie potencjalnie niebezpieczne, gdyż tracimy bezpowrotnie wszystkie zmiany jakich nie wysłaliśmy do repozytorium. HEAD oznacza najbardziej aktualny commit, żeby dostać się do innych commitów, w to miejsce powinniśmy wpisać ich hash SHA1 (bo tak są identyfikowane commity), lub chociaż jego początek. Oczywiście hash ten bierzemy z podglądu historii w logu ;).

Okno na świat

Do tej pory bawiliśmy się tylko lokalnie. O dziwo niewiele więcej nam potrzeba do szczęścia. Praca ze zdalnymi repozytoriami wygląda następująco:

  1. Pobieramy zdalne repozytorium na nasz dysk- git clone adres_repo
  2. Każdorazowo przed rozpoczęciem pracy pobieramy nowe informacje z serwera- git pull origin
  3. Pracujemy tak jak z repozytorium lokalnym
  4. Wysyłamy naszą pracę na serwer- git push (gdyby nie chciało zadziałać- git push origin master)
  5. Powrót do pkt. 2.

Klonowanie pobiera całe repozytorium na nasz dysk (gdybyśmy chcieli tylko pobrać aktualne źródła jakiegoś projektu celem tylko i wyłącznie jego kompilacji, możemy użyć git clone --depth 1 adres_repo). By odrobinę ułatwić sobie pracę możemy podać user@adres_repo zamiast adres_repo- dzięki temu git nie będzie nas pytał za każdym razem o nazwę użytkownika, a jedynie o hasło. Od tej pory możemy pracować tak jak pracowaliśmy wcześniej z naszym lokalnym repozytorium. Trzeba pamiętać, by przed pracą pobrać najnowszą wersję (no, chyba, że pracujemy sami 😉 ). Kiedy mamy już na tyle wykonanej pracy (lub jeśli właśnie złapaliśmy internet) wysyłamy wszystko na serwer.

Jeżeli ktoś wysłał na serwer swoje zmiany podczas naszej pracy (czyli innymi słowy pracujemy na nieaktualnej wersji) i są one w konflikcie z naszymi zmianami, to git nie pozwoli nam wykonać pusha. Naszym zmartwieniem jest zaktualizowanie wersji na której pracujemy, rozwiązanie konfliktów i ponowne wysłanie zmian. Jednak o tym opowiemy sobie przy okazji tworzenia gałęzi i ich łączenia, czyli... następnym razem ;). Powyższe powinno wystarczyć do zabawy i podstawowej pracy oraz zachęcić do dalszego samodzielnego poznawania tego wspaniałego systemu kontroli wersji :). Niecierpliwym polecam książkę Pro Git, dostępną za darmo w sieci, oraz zaprzyjaźnienie się z przełącznikiem --help w poleceniach gita ;).

» «
Tagged as: Komentarze
Komentarze (3) Trackbacks (0)
  1. I o to właśnie chodziło! Treściwy wstęp ‚jak ugryźć gita i się nie zakrztusić’. Już się zabieram za stawianie projektu pod kontrolą tego narzędzia (:

  2. Czytałem szybkie kursy gita i nikt nie opisał tego tak prosto i zwięźle. Od razu zrozumiałem kilka rzeczy nad którymi się zastanawiałem. Dzięki

  3. „git reset HEAD pozwala nam się przenieść do konkretnego commitu, pozostawiając naszą pracę (zmiany w plikach) tak jak były- czyli w stanie z teraźniejszości.”

    I gdy już przejrzymy sobie to co było kiedyś to jak się cofnąć z powrotem do ostatniego commita? czyli po prostu jak cofnąć operację git reset HEAD?

    p.s. Super poradnik :)


Trackbacks are disabled.