Scalanie gałęzi — co to jest, sposoby łączenia i rozwiązywanie konfliktów

Czym jest merge w Git

Merge w Git — to operacja łączenia dwóch lub więcej historii programowania w jedną. Kiedy programista scala gałąź, Git automatycznie znajduje wspólnego przodka (base commit) i tworzy nowy commit scalenia, zawierający zmiany z obu gałęzi. Three-way merge — standardowy algorytm porównujący trzy stany: wspólny przodek, pierwsza gałąź i druga gałąź.

Proces mergowania zaczyna się od polecenia git merge. Git określa punkt rozgałęzienia i sekwencyjnie stosuje zmiany z gałęzi źródłowej na docelową. Jeśli zmiany nie są sprzeczne, Git wykonuje fast-forward lub tworzy merge commit w zależności od ustawień. Fast-forward — scenariusz, w którym gałąź docelowa jest po prostu przesuwana na commity gałęzi źródłowej.

# Przełącz na gałąź docelową i scal
git checkout main
git merge feature/payment-module

# Scal z jawnym no-fast-forward
git merge --no-ff feature/payment-module

# Przerwij scalanie, jeśli konflikty są zbyt złożone
git merge --abort

Flaga --no-ff (no fast-forward) wymusza utworzenie merge commit nawet gdy możliwe jest fast-forward. Pozwala to zachować informację, że zmiany były wykonane w osobnej gałęzi. Wiele zespołów preferuje właśnie takie podejście, aby zachować rozgałęzienie historii w jawnej formie.

Sposoby łączenia gałęzi

W Git istnieją trzy główne strategie łączenia gałęzi, z których każda jest odpowiednia dla określonego scenariusza. Wybór strategii zależy od kultury zespołu i wymagań dotyczących czystości historii projektu.

Standard merge tworzy merge commit z dwoma rodzicami. Pełna historia jest zachowana, ale graf rozgałęzień staje się bardziej złożony. Squash merge łączy wszystkie commity gałęzi feature w jeden i stosuje go na gałęzi docelowej — historia staje się liniowa i czysta, ale traci się informacje o etapach pośrednich.

Rebase, choć nie jest pełnoprawnym mergem, osiąga ten sam rezultat — zmiany z jednej gałęzi są przenoszone na drugą. Różnica polega na tym, że historia jest przepisywana: commity gałęzi feature są tworzone od nowa na ostatnim commicie gałęzi docelowej. Daje to idealnie liniową historię, ale wymaga force push przy wysyłaniu.

Jak rozwiązywać konflikty przy mergowaniu

Konflikt przy mergowaniu występuje, gdy w dwóch gałęziach zmienione zostały te same linie pliku. Git nie może automatycznie określić, którą wersję zachować i wymaga interwencji programisty. Konflikty są wyświetlane w plikach w postaci specjalnych znaczników: <<<<<<<, =======, >>>>>>>.

Proces rozwiązywania konfliktu obejmuje kilka kroków. Najpierw programista otwiera plik z konfliktem i ręcznie wybiera potrzebne zmiany. Ważne jest, aby nie wybierać po prostu jednej z wersji, ale zrozumieć logikę obu zmian i podjąć poprawną decyzję. Po edycji pliku znaczniki konfliktu są usuwane, a zmiany dodawane do staging area przez git add.

# Wyświetl listę plików z konfliktami
git status

# Uruchom mergetool (np. VS Code, IntelliJ)
git mergetool

# Po rozwiązaniu wszystkich konfliktów
git add .
git merge --continue

# Lub przerwij scalanie całkowicie
git merge --abort

Korzystanie z wizualnych narzędzi merge znacznie przyspiesza rozwiązywanie konfliktów. VS Code, IntelliJ IDEA i GitKraken udostępniają interfejsy z trzema panelami: bieżąca gałąź, przychodząca gałąź i wynik. Narzędzie git mergetool automatycznie otwiera skonfigurowany edytor dla każdego pliku z konfliktem.

Najlepszym sposobem uniknięcia złożonych konfliktów jest regularna synchronizacja gałęzi feature z gałęzią główną. Jeśli programista scala main ze swoją gałęzią raz dziennie, konflikty będą niewielkie i łatwe do rozwiązania. Nagromadzenie zmian przez tydzień gwarantuje złożone konflikty z wysokim ryzykiem błędów.

Kiedy używać rebase zamiast merge

Rebase i merge — dwa sposoby łączenia zmian, a wybór między nimi często wywołuje spory w zespołach. Rebase przenosi commity z jednej gałęzi na drugą, przepisując historię. Merge tworzy nowy commit scalenia, zachowując historię rozgałęzień. Każde podejście ma swoje zalety i ograniczenia.

Rebase jest odpowiedni, gdy programista pracuje w swojej lokalnej gałęzi feature i chce uzyskać czystą liniową historię przed utworzeniem Pull Request. Po rebase wszystkie commity układają się sekwencyjnie, bez zbędnych merge commit. Jednak rebase wymaga force push i nie ma zastosowania w gałęziach, nad którymi pracuje kilka osób jednocześnie.

• Rebase — dla osobistych gałęzi feature, gdzie potrzebna jest czysta historia
• Merge — dla wspólnych gałęzi i rejestracji momentu scalenia
• Squash — gdy gałąź feature zawiera wiele drobnych commitów roboczych

Złota zasada Git: nie używaj rebase na commitach, które zostały już wysłane do wspólnego repozytorium. Gwarantuje to, że historia we wspólnej gałęzi pozostaje niezmieniona, a inni programiści nie napotkają zduplikowanych lub utraconych commitów. Do integracji gałęzi feature z główną używaj merge przez Pull Request.

Najlepsze praktyki łączenia gałęzi

Prawidłowy proces mergowania — podstawa stabilnego programowania. W nowoczesnej pracy zespołowej merge wykonuje się nie przez konsolę, ale przez Pull Request na GitHub lub Merge Request w GitLab. PR przechodzi code review, automatyczne sprawdzenia CI i dopiero potem jest mergowany do głównej gałęzi.

Pierwsza praktyka — merguj tylko po przejściu wszystkich sprawdzeń. CI-pipeline powinien zbudować projekt, uruchomić testy i sprawdzić jakość kodu. Jeśli choć jedno sprawdzenie nie przeszło, merge jest blokowany. Nowoczesne platformy (GitHub, GitLab) mają wbudowaną ochronę: branch protection rules automatycznie blokują merge przy nieudanym CI.

Druga praktyka — nigdy nie merguj zepsutego kodu. Przed mergem programista musi upewnić się, że jego zmiany nie psują builda ani nie regresują istniejącej funkcjonalności. Do tego służą automatyczne testy i code review.

Trzecia praktyka — czyść gałęzie feature po mergu. Gałąź, która została już scalona, powinna być usunięta. Zapobiega to dezorientacji i zaśmiecaniu repozytorium. GitHub automatycznie proponuje usunięcie gałęzi po mergu PR, a ustawienia repozytorium można skonfigurować do automatycznego usuwania.