git tutorial – część 1 – wstęp

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

Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.

4 komentarzy

  1. pijoter 24 czerwca 2009 o godz. 12:11 #

    Z książek o GIT polecam "Version Control With Git" wydawnictwa "OReilly". Koszt wersji PDF 28$ ale warto.

    Nie polecam natomiast "Pragmatic Version Control with GIT" z "Pragmatic Bookshelf". Jest tańsa (22$ w wersji PDF) ale napisana nieco mniej przystępnie.

  2. przemoc 25 czerwca 2009 o godz. 3:59 #

    Nie chcę zabrzmieć złośliwie, ale ten tutorial taki dość skąpy jest. Nie lepiej było napisać do szuflady, potem przy kolejnym odstresowaniu (jednym, dwóch czy więcej) uzupełnić i dopiero opublikować coś treściwego? Do bloga to pasuje, ale na artykuł w serwisie średnio.

    "Na szybko" to już lepszy IMO Rusinowy cheat sheet:

    Zack Rusin's Git cheat sheet.

    • Matthew 25 czerwca 2009 o godz. 22:50 #

      Masz rację, że to jednak trochę skąpe jest, jednak wszystko co piszę najpierw ląduje u mnie na blogu a dopiero później, jeżeli ktoś chce, udostępniam to gdzie indziej. Sesja już za mną, więc następne części powinny być już znacznie dłuższe. :)

  3. flamenco108 28 kwietnia 2014 o godz. 10:03 #

    Z dużym opóźnieniem względem daty publikacji, ale jednak napiszę:
    Dzięki Ci bardzo za ten przedwstępny instruktarz. W przeciwieństwie do kolegów – programistów, odczuwałem silny lęk przed programami-repozytoriami kodu, a to dlatego, że ich nie potrzebowałem jako repozytoriów kodu. Ale zawsze chciałem się zaznajomić. A dzięki Tobie mogę chociaż zacząć, bo dostałem secik podstawowych komend. Jeszcze raz dziękuję ;-)

(wymagane)
URI
Uwaga! Niektóre komentarze, m.in. te dodane przez niezalogowanych i nowych użytkowników, są ręcznie moderowane. Jeśli Twój komentarz nie ukaże się od razu, nie dodawaj go ponownie, tylko cierpliwie poczekaj na akceptację.

Literówki najlepiej zgłaszać mailem: sirmacik@jakilinux.org!

W komentarzach możesz używać prostych znaczników HTML. Przykłady:
  • Link: <a href="jaklinux.org">Linux dla każdego</a>,
  • Wytłuszczenie: <strong>tekst pogrubiony</strong>,
  • Kursywa: <em>tekst pochylony</em>,
  • Przekreślenie: <del>tekst przekreślony</del>,
  • Kod: <code>printf("blok kodu");</code>,
  • Cytat: <blockquote>cytat</blockquote>
Uwaga: jeśli dodasz nieznany znacznik, będzie on niewidoczny, gdyż system filtruje takie znaczniki.