Czym jest Git i jakie problemy rozwiązuje?

Git to rozproszony system kontroli wersji (DVCS – Distributed Version Control System), stworzony przez Linusa Torvaldsa w 2005 roku. Rozwiązuje problemy związane z:

• Śledzeniem zmian w plikach i współpracą wielu osób nad jednym projektem.
• Przechowywaniem pełnej historii projektu lokalnie, co umożliwia pracę offline.
• Tworzeniem gałęzi (ang. branches) i łączeniem (ang. merge) bez konieczności ciągłego połączenia z serwerem centralnym.

Polecane materiały:

• Pro Git Book (pl)
• Atlassian: What is Git?

Jak wygląda typowy przepływ pracy (workflow) w Git?

1. Klon lub inicjalizacja: Najpierw klonujemy istniejące repozytorium (git clone <url>) lub tworzymy nowe (git init).
2. Praca lokalna: Wprowadzamy zmiany w plikach. Możemy sprawdzić status za pomocą git status.
3. Staging: Dodajemy wybrane zmiany do poczekalni (stage) za pomocą git add <plik> lub git add ..
4. Commit: Zatwierdzamy dodane zmiany poleceniem git commit -m "opis zmian".
5. Push: Wysyłamy commity na serwer (git push).
6. Pull: Pobieramy i scalamy zmiany innych osób z repozytorium zdalnego (git pull).

Polecane materiały:

• Pro Git Book (pl): Podstawy pracy z Git

Jaka jest różnica między git pull a git fetch?

• git fetch: Pobiera zmiany (commity, gałęzie) z repozytorium zdalnego, ale nie scala ich automatycznie z lokalną gałęzią. Pozwala to wcześniej przejrzeć zmiany.
• git pull: Wykonuje git fetch i następnie automatycznie git merge (lub git rebase, zależnie od konfiguracji), scalając pobrane zmiany z bieżącą gałęzią.

Polecane materiały:

• Pro Git Book (pl): Zdalne gałęzie
• Atlassian: Różnica między fetch a pull (angielski)

W jaki sposób tworzyć i przełączać się między gałęziami?

• Tworzenie nowej gałęzi:

git branch <nazwa_gałęzi>

• Przełączanie się na istniejącą gałąź:

git checkout <nazwa_gałęzi>

• Utworzenie gałęzi i natychmiastowe przełączenie:

git checkout -b <nazwa_gałęzi>

lub (nowsza składnia):

git switch -c <nazwa_gałęzi>

Polecane materiały:

• Pro Git Book (pl): Tworzenie i scalanie gałęzi

Jakie są różnice między git merge a git rebase?

• git merge: Tworzy nowy commit scalający (tzw. merge commit), zachowując historię obu gałęzi w formie nieliniowej. Wygodne, jeśli chcesz zachować pełną informację o tym, kiedy i skąd przyszły zmiany.
• git rebase: Przepisuje historię, przenosząc commity jednej gałęzi na wierzch drugiej, co daje bardziej „liniową" historię. Przydaje się, gdy chcemy uzyskać przejrzysty ciąg commitów, ale wiąże się z ryzykiem konfliktów przy współpracy w zespole (jeśli gałąź jest publiczna).

Polecane materiały:

• Pro Git Book (pl): Rebase
• Atlassian: Merging vs. Rebasing (angielski)

Co się dzieje w przypadku konfliktu podczas scalania i jak go rozwiązać?

Konflikt występuje, gdy Git nie potrafi automatycznie połączyć zmian z dwóch źródeł (np. edycji tego samego wiersza w obu gałęziach). Aby go rozwiązać:

1. Otwórz plik z konfliktem i odszukaj fragmenty oznaczone <<<<<<<, ======= oraz >>>>>>>.
2. Ręcznie wybierz lub połącz właściwe zmiany, a następnie usuń znaczniki konfliktów.
3. Dodaj rozwiązane pliki do stage (git add <plik>).
4. Zakończ scalanie za pomocą git commit (w przypadku merge) lub git rebase --continue (w przypadku rebase).

Polecane materiały:

• Pro Git Book (pl): Rozwiązywanie konfliktów

Jakie są różnice między git reset, git revert a git checkout?

• git reset: Zmienia wskaźnik HEAD i potencjalnie modyfikuje indeks (staging area) oraz katalog roboczy. Pozwala cofnąć commity lokalnie, a także przenieść zmiany z powrotem do stage lub do katalogu roboczego.
• git revert: Tworzy nowy commit, który odwraca zmiany wprowadzone we wskazanym commicie. Historia nie jest przepisywana, więc jest to rozwiązanie bezpieczne dla repozytoriów współdzielonych.
• git checkout: W kontekście cofania zmian służy np. do przywrócenia konkretnego pliku z określonego commitu (git checkout <commit> -- <plik>) lub do przeskoczenia do innego commita w trybie detached HEAD.

Polecane materiały:

• Pro Git Book (pl): Odzyskiwanie danych
• Atlassian: Resetting, reverting, and undoing changes (angielski)

Czym jest i do czego służy git stash?

git stash służy do tymczasowego zapisania niezacommitowanych zmian (zarówno tych w staging area, jak i w katalogu roboczym) i przywrócenia czystego stanu katalogu roboczego. Pozwala to np. na szybkie przełączenie gałęzi bez konieczności commitowania lub tracenia wprowadzonych zmian.

• git stash – zapisuje zmiany do kolejki.
• git stash pop – przywraca ostatnio zapisane zmiany i usuwa je z listy.
• git stash list – wyświetla listę zapisanych zmian.
• git stash apply – przywraca zmiany, ale nie usuwa ich z listy (można je zastosować ponownie).

Polecane materiały:

• Pro Git Book (pl): Stash
• Atlassian: Git stash (angielski)

Jak wyświetlić historię commitów w Git?

Do wyświetlenia historii commitów w Git służy polecenie:

git log

Można je wzbogacić przełącznikami (np. --oneline, --graph, --decorate) w celu uzyskania bardziej czytelnego lub skróconego podglądu historii.

Przykład:

git log --oneline --graph --decorate

Daje to zwizualizowane informacje o gałęziach, punktach scalenia i skróconych identyfikatorach commitów.

Polecane materiały:

• Pro Git Book (pl): Historię można przeglądać w rozdziale "Podstawy pracy z Git"
• Atlassian: Git log (angielski)

Jaka jest różnica między git log a git reflog?

• git log pokazuje historię commitów dostępną w gałęziach, czyli sekwencję widzianą publicznie w repozytorium (wskazaną przez HEAD lub referencje).
• git reflog śledzi całą aktywność lokalną związaną z przesuwaniem wskaźnika HEAD, nawet jeśli nie jest dostępna w zwykłym git log. Zawiera informacje o przełączaniu gałęzi, cofaniu commitów, rebase, itp., dzięki czemu można odzyskać commity, które np. zostały overspisane rebase'em lub usunięte w wypadku zmiany referencji.

Polecane materiały:

• Pro Git Book (pl): Reflog i zapis operacji HEAD
• Atlassian: Log vs. Reflog (angielski)

Czym jest Gitflow i kiedy warto go stosować?

Gitflow to zdefiniowany model pracy z gałęziami w Git, który rozdziela linię rozwoju na gałąź główną (np. master lub main) i gałąź rozwojową (develop). Dodatkowo wykorzystuje się gałęzie funkcjonalne (feature branches), gałęzie przygotowujące do wydania (release branches) oraz gałęzie hotfix (do szybkich poprawek w stabilnym wydaniu).

Gitflow sprawdza się w:

• Projektach o jasno ustalonych cyklach wydawniczych.
• Zespołach, w których wiele osób pracuje równolegle nad różnymi funkcjonalnościami.
• Projektach wymagających ścisłej kontroli wersji (m.in. w branży enterprise).

Polecane materiały:

• Atlassian: Wprowadzenie do Gitflow (angielski)
• Pro Git Book (pl): Omawiana struktura gałęzi w większych projektach

Jakie strategie pomogą unikać konfliktów scalania w środowisku zespołowym?

1. Częste i małe commity: Szybkie przesyłanie zmian ułatwia wykrycie ewentualnych konfliktów.
2. Regularne aktualizowanie gałęzi: Wciąganie (git pull / git fetch + merge/rebase) zmian z głównej gałęzi.
3. Dobra komunikacja w zespole: Informowanie współpracowników o trwających pracach nad określonymi sekcjami kodu.
4. Rozdzielanie zadań: Dbanie, aby wiele osób nie dokonywało jednoczesnych, dużych zmian w tych samych obszarach plików.

Polecane materiały:

• Atlassian: Zapobieganie konfliktom i strategia scalania (angielski)

Czym różni się git rebase --interactive od zwykłego rebase?

• Zwykłe git rebase <branch> przenosi wszystkie commity z bieżącej gałęzi na szczyt innej gałęzi (np. master czy main) w sposób automatyczny i zachowuje oryginalną liczbę commitów, ale zmienia ich identyfikatory (SHA).
• git rebase --interactive (i tzw. rebase interaktywny) pozwala na ręczną edycję listy commitów przed ich przeaplikowaniem. Dzięki temu można:
  • Zmieniać kolejność commitów,
  • Squashować (łączyć) kilka commitów w jeden,
  • Edytować treść commitów (np. wiadomość o commicie),
  • Usuwać zbędne commity.

Interaktywny rebase jest szczególnie przydatny wtedy, gdy chcesz uporządkować historię przed scaleniem z gałęzią główną (np. w celu zachowania czytelnego, liniowego ciągu commitów).

Polecane materiały:

• Pro Git Book (pl): Rebase interaktywny
• Atlassian: Interactive rebase (angielski)

Jaki jest cel cherry-picking i jak go użyć?

Cherry-picking umożliwia skopiowanie (przeaplikowanie) wybranego commita (lub commitów) z jednej gałęzi do innej, bez łączenia pozostałych zmian w gałęzi źródłowej. Pozwala to na zaciągnięcie konkretnej modyfikacji – np. poprawki błędu – bez potrzeby wykonywania pełnego merge.

Polecenie:

git cherry-pick <sha1_commita>

W rezultacie na bieżącej gałęzi pojawi się commit zawierający identyczne zmiany (choć z nowym identyfikatorem).

Polecane materiały:

• Pro Git Book (eng): Cherry-pick
• Atlassian: Jak korzystać z cherry-pick (angielski)

Jak działają submoduły (submodules) w Git i dlaczego warto z nich korzystać?

Submoduły pozwalają na osadzenie jednego repozytorium Git wewnątrz innego jako podkatalog. Daje to możliwość utrzymywania zależnych projektów w odseparowanych repozytoriach, przy jednoczesnym zachowaniu powiązania z głównym repozytorium. Jest to przydatne np. gdy:

• Chcesz używać zewnętrznej biblioteki (z własnym repozytorium),
• Potrzebujesz wspólnego modułu, który jest rozwijany niezależnie i używany w wielu projektach.

Przykładowe polecenia:

git submodule add https://github.com/użytkownik/projekt-biblioteka.git ścieżka/do/modułu
git submodule update --init --recursive

Polecane materiały:

• Pro Git Book (pl): Praca z submodułami
• Atlassian: Submodules (angielski)

Czym jest Git garbage collection (GC) i kiedy jest uruchamiana?

Git garbage collection to proces porządkowania i optymalizacji wewnętrznej struktury repozytorium. Podczas GC:

• Nieużywane obiekty (np. stare, nieosiągalne commity) są usuwane lub oznaczane do usunięcia.
• Dane w plikach pakietowych (pack files) mogą być konsolidowane, co zmniejsza rozmiar repozytorium i przyspiesza działania Gita.

GC jest wywoływana automatycznie przez Gita po wykonaniu określonej liczby operacji (np. commitów, push/pull itp.) lub można ją uruchomić ręcznie poleceniem:

git gc

Polecane materiały:

• Pro Git Book (pl): Git-Internals – Garbage collection
• Atlassian: Git garbage collection (angielski)