Projekt GIT można rozpocząć poprzez utworzenie inicjalizację repozytorium GIT w istniejącym katalogu lub sklonowaniu istniejącego repozytorium z innego serwera. W celu szkoleniowym utworzymy projekt GitTutorial zawierający dwa pliki GitTutorial1.txt oraz GitTutorial2.txt.

Inicjalizacja GIT w istniejącym katalogu

Aby rozpocząć śledzenie zmian w plikach istniejącego projektu należy w katalogu projektu wydać polecenie:

> git init

Spowoduje to utworzenie ukrytego folderu .git w którym umieszczone są niezbędne do pracy z repozytorium pliki, jest to szkielet repozytorium. W tym momencie żadne pliki nie są jeszcze śledzone. Aby pliki zostały śledzone należy dodać je do przechowalni (staging area). Dodanie istniejącego pliku odbywa się za pomocą komendy git add. Dodanie pliku GitTutorial1.txt odbywa się za pomocą komendy:

> git add GitTutorial1.txt

Aby dodać wszystkie pliki i podfoldery w bieżącym folderze należy użyć komendy:

> git add .

Teraz wszystkie pliki znajdują się w przechowalni. Aby podejrzeć status plików w naszym projekcie używamy komendy git status:

> git status

Wynik komendy widoczny jest na zdjęciu:

Zatwierdzenie zmian do repozytorium

Zatwierdzenia zmian dokonujemy poleceniem git commit. Wydanie tego polecenia spowoduje otwarcie okna edytora w którym możemy dodać opis. opis mozna dodać również w komendzie za pomocą parametru -m:

> git commit -m "Pierwszy commit"

GIT nie ma liczbowych numerów rewizji tak jak np SVN. Każdy commit określony jest skrótem SHA-1 wyliczanym na podstawie zawartości. Jest to cecha która umożliwia prowadzenie wielu równoległych repozytoriów. Aby cofnąć zmiany w projekcie wystarczy podać ilość pierwszych znaków które jednoznacznie identyfikują rewizję. Zwykle podaje się siedem pierwszych znaków klucza. Istnieje ułatwienie pozwalające na oznaczenie wszystkich zmienionych plików jako śledzonych i wykonanie na nich commita, jest to parametr -a komendy commit. Zmieńmy plik GitTutorial1.txt i zapiszmy zmiany:

> echo "dopisz na końcu" >> GitTutorial1.txt

> git commit -a -m "Zapis wszystkich zmian"

Należy pamiętać, że komenda: git commit -a  nie działa na nowe pliki i trzeba je zawsze dodać do przechowalni za pomocą git add.

Sprawdzanie zmian w repozytorium

Komenda umożliwiająca sprawdzenie historii repozytorium to git log. Przydatnymi parametrami komendy git log są:

• --pretty-online  - pokazuje klucz sha i opis w jednej lini.
• --abbrev-commit - skraca skrót SHA-1 do siedmiu znaków.

> git log --pretty=oneline --abbrev-commit

Cofanie zmian

Jeżeli plik został zmodyfikowany ale nie jest jeszcze śledzony to cofnięcie zmian odbywa się za pomocą komendy git checkout: Sprawdźmy używając następującej sekwencji komend:

> git status
> echo "nowy tekst na końcu" >> GitTutorial2.txt
> git status
> git checkout GitTutorial2.txt
> git status

Jeżeli nie podamy nazwy to wszystkie zmiany w katalogu roboczym zostaną cofnięte. Pliki śledzone tzn znajdujące się w poczekalni muszą zostać z niej wyjęte przed cofnięciem zmian. Służy do tego komenda git reset HEAD. HEAD oznacza ostatnią wersję. Przykład:

> echo "nowy tekst na końcu" >> GitTutorial2.txt
> git add GitTutorial2.txt
> git status
> git reset HEAD GitTutorial2.txt
> git status

Cofanie zatwierdzonych zmian

Cofnięcie się do uprzednio zapisanych zmian w repozytorium odbywa się z użyciem komendy git revert i skrótu SHA-1 wersji. Przykład:

> echo "nowy tekst na końcu" >> GitTutorial2.txt
> git commit -a -m "Zmiana do wycofania"
> git log --pretty=oneline --abbrev-commit
> git revert 9228ce2
> git log --pretty=oneline --abbrev-commit

Porównywanie wersji

Podgląd listy zmian odbywa się z użyciem komendy:

> git log -p

Różnice pomiędzy kopią roboczą a konkretną wersją oglądamy za pomocą komendy:

> git show 9228ce2

Gdzie 9228ce2 to początek skrótu SHA-1 konkretnej wersji. Różnice między wersjami w repozytorium oglądamy za pomocą komendy:

> diff 9228ce2..9521e7f

Tagowanie

Git posiada możliwość tagowania konkretnych miejsc w historii istnienia repozytorium. przegląd wszystkich istniejących tagów GITA odbywa się za pomocą komendy:

> git tag

Etykiety wyświetlane są alfabetycznie, bez względu na kolejność z jaką zostały utworzone. Przeszukanie etykiet wg wzorca odbywa się z użyciem komendy:

> git tag -l '<wzorzec>.*'

Git używa dwóch rodzajów tagów tzw lekkich i opisanych. Lekkie są tylko wskaźnikiem do konkretnej rewizji natomiast tagi opisane są przechowywane jako pełne obiekty w bazie danych, posiadają sumę kontrolną, dane identyfikujące użytkownika oraz notatkę. Zaleca się aby przy tworzeniu etykiet opisanych wypełnić wszystkie dane.

Tworzenie tagów opisanych

Utworzenie tagu opisanego odbywa się z użyciem komendy:

> git tag -a <nazwa_taga> -m ''

Przykładowe utworzenie taga wygląda tak:

> git tag -a git_tutorial_v_1.0.0 -m 'Pierwsza otagowana wersja.'

Dane taga oraz rewizji można zobaczyć za pomocą polecenia:

> git show <nazwa_taga>

Dane utworzonego wcześniej taga możemy podejrzeć używając polecenia:

> git show git_tutorial_v_1.0.0

Tworzenie tagów lekkich

Tag lekki jest to zapisana w pliku suma kontrolna oznaczonej rewizji. Dodanie lekkiego tagu odbywa się za pomocą polecenia:

> git tag <nazwa_taga>

Przykładowe utworzenie lekkiego taga wygląda tak:

> git tag git_tutorial_v_1.0.1

Tagowanie historycznych rewizji

Aby dodać etykietę do rewizji historycznej należy podać sumę kontrolną lub jej identyfikującą część na końcu polecenia, przykładowo wykonanie tagu drugiej zatwierdzonej wersji wygląda tak:

> git log --pretty=oneline
> git tag git_tutorial_v_0.0.1 9228ce24
> git show git_tutorial_v_0.0.1

Wysyłanie tagów do zdalnego repozytorium

Domyślnie komenda git push nie wysyła tagów do zdalnego repozytorium. Wysłanie etykiety na serwer odbywa się za pomocą komendy:

> git push origin <nazwa_taga>

Aby wysłać wszystkie utworzone tagi należy użyć parametru --tags zamiast nazwy konkretnego taga:

> git push origin --tags