W większości współczesnych projektów programistycznych Git jest standardowym narzędziem pracy. Nawet przy mniejszych aplikacjach trudno dziś wyobrazić sobie rozwój oprogramowania bez kontroli wersji, branchy czy współpracy zespołowej.
Do tej pory miałem okazję korzystać głównie z podstawowych operacji Gitowych w codziennej pracy developerskiej, dlatego postanowiłem uporządkować wiedzę i lepiej zrozumieć cały workflow pracy z repozytorium.
Czym właściwie jest Git?
Git to rozproszony system kontroli wersji.
Pozwala śledzić zmiany w kodzie, wracać do wcześniejszych wersji projektu oraz pracować zespołowo nad jedną aplikacją.
Największą zaletą Gita jest możliwość bezpiecznego rozwijania projektu bez ryzyka utraty wcześniejszych zmian.
Typowy workflow wygląda mniej więcej tak:
pobranie projektu,
stworzenie osobnego brancha,
wprowadzenie zmian,
commit zmian,
wysłanie kodu do repozytorium,
code review i merge.

Najczęściej używane komendy Git
Inicjalizacja repozytorium

git init

Tworzy nowe repozytorium Git w katalogu projektu.

Klonowanie istniejącego projektu

git clone https://adres-repozytorium.git

Pozwala pobrać projekt z serwera na komputer lokalny.

Sprawdzenie statusu zmian

git status

Jedna z najczęściej używanych komend.
Pokazuje:
zmodyfikowane pliki,
nowe pliki,
pliki oczekujące na commit.

Dodawanie plików do commita

git add .

Dodaje wszystkie zmiany do tzw. staging area.
Można również dodać pojedynczy plik:

git add index.php


Tworzenie commita

git commit -m "Dodano formularz logowania"

Commit zapisuje aktualny stan zmian wraz z opisem.

Pobieranie zmian z repozytorium

git pull

Synchronizuje lokalne repozytorium z wersją znajdującą się na serwerze.

Wysyłanie zmian

git push

Publikuje lokalne commity w zdalnym repozytorium.

Branche i praca zespołowa
Jedną z najważniejszych funkcji Gita są branche.
Branch pozwala pracować nad nową funkcjonalnością bez ingerowania w główną wersję aplikacji.
Najczęściej spotykane branche:
main
develop
feature/nazwa-funkcji
bugfix/nazwa-poprawki
Tworzenie nowego brancha:

git checkout -b feature/login

Dzięki branchom kilka osób może jednocześnie rozwijać różne części projektu.

Pull Request i Code Review
W pracy zespołowej standardem jest korzystanie z:
Pull Requestów,
Merge Requestów,
Code Review.
Po zakończeniu pracy nad funkcjonalnością developer wysyła zmiany do repozytorium i tworzy request o połączenie kodu z główną gałęzią projektu.
Wtedy inny programista może:
przejrzeć kod,
zgłosić poprawki,
zatwierdzić merge.
To pomaga utrzymać jakość projektu i ograniczyć liczbę błędów.

GitHub a GitLab — najważniejsze różnice
Najczęściej Git jest używany razem z platformami takimi jak:
GitHub
GitLab
Obie platformy służą do hostowania repozytoriów Git i wspierają współpracę zespołową, jednak różnią się podejściem i dodatkowymi funkcjami.
GitHub
GitHub jest najpopularniejszą platformą Gitową na świecie.
Bardzo mocno kojarzy się z projektami open source oraz społecznością programistów.
Najważniejsze cechy:
prosty i przejrzysty interfejs,
ogromna społeczność,
popularność w projektach open source,
integracje z wieloma narzędziami.

GitLab
GitLab jest bardziej rozbudowany pod kątem DevOps i procesów CI/CD.
Często wybierają go firmy rozwijające większe systemy wewnętrzne lub korzystające z własnej infrastruktury.
Najważniejsze funkcje:
wbudowane pipeline’y CI/CD,
integracje deploymentowe,
możliwość self-hostingu,
rozbudowane zarządzanie projektami.

Git w codziennej pracy developera
Nawet podstawowa znajomość Gita jest dziś praktycznie obowiązkowa w pracy programisty.
Najczęściej wykorzystywane elementy to:
commitowanie zmian,
praca na branchach,
pull/push,
rozwiązywanie konfliktów,
code review,
współpraca przez Pull Requesty lub Merge Requesty.
Git bardzo usprawnia pracę zespołową i pozwala bezpiecznie rozwijać aplikacje niezależnie od ich wielkości.