Skip to content

Git dla Zespołów i Zaawansowanych: Workflow i Gałęzie

Ten dokument wyjaśnia koncepcje pracy z systemem Git wykraczające poza proste zapisywanie zmian. Dowiesz się tutaj, jak pracować równolegle nad różnymi funkcjami, jak łączyć kod z innymi programistami i jak dbać o czystość projektu.

1. Konfiguracja Tożsamości (Niezbędne na start)

Zanim zaczniesz tworzyć historię projektu, Git musi wiedzieć, kim jesteś. Te dane będą widoczne przy każdym Twoim commicie.

git config --global user.name "Twoje Imie"
git config --global user.email "twoj.email@przyklad.com"

To ustawienie jest jednorazowe dla całego systemu. Bez tego Twoje zmiany będą podpisane jako nieznany użytkownik, co utrudnia współpracę.

2. Praca na Gałęziach (Branches)

Gałęzie to jedna z najpotężniejszych funkcji Gita. Wyobraź sobie je jako równoległe linie czasowe projektu.

  • Main/Master: To główna, stabilna wersja kodu (produkcyjna).
  • Feature Branch: To kopia kodu, na której pracujesz nad nową funkcją. Możesz tu psuć i eksperymentować bez ryzyka uszkodzenia głównego projektu.

Dlaczego używamy gałęzi?

Dzięki nim wiele osób może pracować nad różnymi plikami w tym samym czasie, nie wchodząc sobie w drogę.

Zarządzanie Gałęziami

Tworzenie nowej gałęzi i przełączenie się na nią: Najczęściej używana komenda. Tworzy nową linię czasu od miejsca, w którym aktualnie jesteś.

git checkout -b nazwa-twojej-galenzi
# Lub w nowszych wersjach Gita:
git switch -c nazwa-twojej-galenzi

Podgląd gałęzi: Sprawdź, jakie gałęzie istnieją i na której aktualnie się znajdujesz (oznaczona gwiazdką *).

git branch

Przełączanie się między gałęziami:

git checkout nazwa-innej-galenzi
# Lub nowocześniej:
git switch nazwa-innej-galenzi

3. Scalanie Zmian (Merge)

Gdy skończysz pracę na swojej gałęzi (np. nowa-funkcja), musisz połączyć ją z główną gałęzią (main).

  1. Przełącz się na gałąź, do której chcesz scalić zmiany (zazwyczaj main): 
    git checkout main
  2. Wykonaj scalenie: 
    git merge nowa-funkcja

Jeśli nikt nie zmieniał tych samych linii kodu co Ty w międzyczasie, Git wykona tzw. Fast-forward. Jeśli zmiany się nakładają, wystąpi Konflikt.

4. Konflikty (Merge Conflicts)

Konflikt to sytuacja, w której Git nie wie, którą wersję kodu zachować (np. dwie osoby zmieniły ten sam linijkę w tym samym pliku).

Jak rozwiązać konflikt? 1. Git poinformuje Cię o konflikcie podczas git merge lub git pull. 2. Otwórz plik w edytorze kodu. Zobaczysz znaczniki: 

<<<<<<< HEAD
Kod, który był w gałęzi głównej
=======
Kod, który napisałeś Ty
>>>>>>> nowa-funkcja
3. Ręcznie wybierz poprawny kod, usuń znaczniki Git'a (<<<<, ====, >>>>) i zapisz plik. 4. Dodaj poprawiony plik i zatwierdź: 
git add plik_z_konfliktem.txt
git commit -m "Rozwiązanie konfliktu"

5. Pull Requesty (PR) / Merge Requesty

Pull Request (PR) to funkcja platform hostingowych (GitHub, GitLab, Bitbucket), a nie samego Gita, ale jest kluczowa w nowoczesnym programowaniu.

Zamiast scalać (merge) kod lokalnie na swoim komputerze i wypychać go do main na serwerze, robisz to bezpieczniej:

  1. Wypychasz swoją gałąź (nowa-funkcja) na serwer: 
    git push origin nowa-funkcja
  2. Wchodzisz na stronę repozytorium (np. GitHub).
  3. Klikasz "New Pull Request" (lub "Compare & Pull Request").
  4. Code Review: To moment dyskusji. Inni programiści widzą Twoje zmiany, mogą je komentować i prosić o poprawki zanim kod trafi do main.
  5. Po zatwierdzeniu przez zespół, klikasz przycisk Merge na stronie.

Dzięki temu main jest chroniony przed błędami i niesprawdzonym kodem.

6. .gitignore - Ignorowanie Plików

Nie wszystko powinno trafić do repozytorium. Pliki tymczasowe, hasła, lokalne konfiguracje środowiska czy gigantyczne foldery bibliotek (jak node_modules w JS czy venv w Pythonie) powinny być ignorowane.

W tym celu tworzy się plik o nazwie .gitignore w głównym katalogu projektu.

Przykładowa zawartość .gitignore: 

# Logi systemowe
*.log

# Pliki środowiskowe (często zawierają hasła!)
.env

# Foldery instalacyjne
node_modules/
dist/
build/

7. Git Stash - Schowek

Czasami pracujesz nad czymś ("brudna robota"), ale musisz pilnie przełączyć się na inną gałąź, żeby naprawić błąd. Nie chcesz jeszcze robić commita, bo kod nie działa.

Użyj schowka:

  1. Schowaj zmiany: 
    git stash
    Twój katalog roboczy jest teraz czysty (jak po ostatnim commicie).
  2. Zrób to, co musisz na innej gałęzi.
  3. Wróć i przywróć zmiany: 
    git stash pop

Podsumowanie Workflow (Cykl Pracy)

Profesjonalny cykl pracy w Gicie wygląda zazwyczaj tak:

  1. Pobierz najnowsze zmiany: git checkout main -> git pull origin main
  2. Stwórz gałąź na zadanie: git checkout -b fix-header
  3. Pracuj i zapisuj: git add . -> git commit -m "Poprawa nagłówka"
  4. Wypchnij gałąź: git push origin fix-header
  5. Utwórz Pull Request na GitHubie/GitLabie.
  6. Czekaj na Code Review i ewentualnie wprowadzaj poprawki.
  7. Zscal (Merge) PR na platformie hostingowej.
  8. Wyczyść: Usuń lokalną gałąź git branch -d fix-header.