Ręczne rozwiązywanie konfliktów scalania

Witamy w świecie konfliktów scalania! Proszę się nie martwić — są one normalną częścią współpracy z użyciem Gita. Konflikt scalania występuje, gdy Git nie potrafi automatycznie ustalić, jak połączyć zmiany z dwóch różnych gałęzi.

Zwykle dochodzi do tego, gdy dwie gałęzie modyfikują te same wiersze w tym samym pliku na różne sposoby albo gdy jedna gałąź usuwa plik zmodyfikowany przez inną gałąź.

Git doskonale radzi sobie z automatycznym scalaniem większości zmian. Gdy napotyka niejednoznaczność, potrzebuje jednak pomocy człowieka. Oto typowe sytuacje:

• Ten sam wiersz, różne zmiany: Dwie osoby w różny sposób edytują dokładnie ten sam wiersz kodu.
• Jedna osoba usuwa, druga modyfikuje: Jedna gałąź usuwa plik, a inna go modyfikuje.
• Zmiana nazwy a modyfikacja: W jednej gałęzi zmieniono nazwę pliku, a w innej go zmodyfikowano.

Gdy wystąpi konflikt scalania, Git nie zakończy scalania automatycznie. Zamiast tego wstrzyma proces i poinformuje, w których plikach występują konflikty. Zobaczy Pan komunikat podobny do tego:

Po nieudanym scalaniu automatycznym repozytorium znajdzie się w stanie „scalania”. Za pomocą git status można sprawdzić, w których plikach występują konflikty. Pliki te zostaną wyświetlone jako „unmerged paths”.

Git wstawia specjalne znaczniki bezpośrednio do plików zawierających konflikty, aby wskazać miejsce problemu. Znaczniki te pomagają zidentyfikować różne wersje kodu:

• <<<<<<< HEAD: Oznacza początek zmian z bieżącej gałęzi.
• =======: Oddziela zmiany z obu gałęzi.
• >>>>>>> branch-name: Oznacza koniec zmian z przychodzącej gałęzi.

Przyjrzyjmy się przykładowi. Załóżmy, że ma Pan plik hello.txt. W gałęzi main zmieniono jego zawartość na „Hello from main”, a w gałęzi feature ten sam wiersz zmieniono na „Greetings from feature”. Podczas scalania feature z main plik będzie wyglądać tak:

Należy otworzyć plik zawierający konflikt (na przykład hello.txt) w edytorze tekstu. Następnie trzeba ręcznie edytować plik, usunąć znaczniki konfliktu i wybrać żądaną zawartość. Można połączyć fragmenty, wybrać jedną z wersji albo napisać coś zupełnie nowego.

W przypadku naszego przykładu z plikiem hello.txt, jeśli chcemy zachować oba komunikaty, możemy zmienić go tak:

Po ręcznej edycji pliku i usunięciu wszystkich znaczników konfliktu należy poinformować Gita, że konflikt został rozwiązany. W tym celu trzeba dodać plik do obszaru staging za pomocą git add.

Należy powtórzyć tę czynność dla każdego pliku wymienionego przez git status jako „unmerged paths”.

Po dodaniu do obszaru staging wszystkich plików zawierających konflikty scalanie jest gotowe do zatwierdzenia. Git zazwyczaj wyświetli domyślny komunikat commita scalającego, który można zaakceptować lub zmodyfikować. Ten końcowy commit kończy proces scalania.

Konflikt scalania został pomyślnie rozwiązany. Sprawdźmy teraz, czy rozumie Pan kolejny ważny krok po ręcznej edycji pliku zawierającego konflikt.

Opanował(a) Pan/Pani ręczne rozwiązywanie konfliktów scalania! To podstawowa umiejętność każdego dewelopera.

• Konflikty występują, gdy Git nie może automatycznie scalić zmian.
• git status pokazuje niescalone pliki.
• Znaczniki konfliktu (<<<<<<<, =======, >>>>>>>) wskazują rozbieżny kod.
• Należy ręcznie edytować pliki, usunąć znaczniki i wybrać ostateczną zawartość.
• Rozwiązane pliki należy dodać do obszaru przechowalni za pomocą git add.
• Scalanie należy zakończyć poleceniem git commit.

Praktyka czyni mistrza! Na początku konflikty mogą wydawać się onieśmielające, ale dzięki tym krokom opanuje je Pan/Pani.