Git #8: Małe i wielkie konflikty

W większości przypadków Git automatycznie scala nowe zmiany. Gdy kilku ludzi pracuje na tym samym pliku lub gdy jedna osoba skasuje plik, nad którym aktualnie pracuje ktoś inny, może to doprowadzić do tak zwanego konfliktu. Sam konflikt ujawnia się w momencie np. gdy chcemy spush’ować commita’ z lokalnego do zdalnego repozytorium po kimś, kto już edytował ten sam plik w tym samym czasie co my i wrzucił zmiany przed nami. Konflikty możemy rozwiązywać różnymi narzędziami, takimi jak kdiff3 czy kompare. Jednak w tej serii wspomagamy się PyCharmem i również w kwestii rozwiązywania konfliktów jest on bardzo pomocny.

Przykład konfliktu

Zacznijmy od stworzenia konfliktu. Utworzymy nowe repozytorium (gałąź domyślna: master), które będzie zawierało plik testfile.py. Następnie na podstawie gałęzi master utwórzmy rozgałęzienia change_1 i change_2.

Przełącz się na gałąź change_1 i wyedytuj plik testfile.py. Po wprowadzeniu zmian utwórz commit i wrzuć zmiany do zdalnego repozytorium.

Następnie przejdź na gałąź change_2, wyedytuj plik testfile.py (Wprowadź inny fragment kodu niż w poprzednim kroku). Utwórz commit na gałęzi change_2 i podobnie jak wcześniej umieść zmiany na zdalnym repozytorium. Tak przygotowane repozytoria będziemy scalać z gałęzią master za pomocą komendy git merge. Przejdź na repozytorium master i scal najpierw change_1:

pi@raspberrypi:~/test_1 $ git merge change_1

Ta operacja powinna zakończyć się sukcesem i zmiany z gałęzi change_1 znaleźć się w gałęzi master. Możesz powtórzyć te operacje z linii komend z change_2. Efektem czego uzyskamy konflikt, którego efekt będzie widoczny w pliku testfile.py:

<<<<<<< HEAD
print("testfile changed in branch change_1")
=======
print("testfile changed in branch change_2")
>>>>>>> change_2

Taki konflikt możesz oczywiście rozwiązać ręcznie, kasując niechciane linijki. Jednak taki sposób jest zalecany tylko i wyłącznie przy niewielkich zmianach. Gdy zmian jest dużo i są rozrzucone po całym pliku, taki sposób rozwiązywania konfliktów może przynieść dużo więcej złego niż dobrego.

Rozwiązanie konfliktu

Jeśli jednak chcesz obsłużyć konflikt w bardziej profesjonalny sposób, zamiast użycia linii komend, użyjesz do tej operacji pyCharma. Wybierając z paska opcji VCS -> Git -> Merge changes, otrzymasz okno, w którym możesz wybrać jaka gałąź ma być zaciągnięta do aktualnie wybranego branch’a. Zaznacz change_2, a następnie przyciśnij przycisk Merge.

Twoim oczom ukaże się okno z listą plików, w których zaszły konflikty podczas tego scalania.

Już w tym momencie możemy wybrać czy chcemy zatrzymać zmiany, które są aktualnie na masterze (w naszym przypadku zaciągnięte z change_1) wybierając opcje Accept Yours. Czy może jednak zmiany ze scalanej gałęzi change_2 (przycisk Accept Theirs). Jeżeli jednak chcemy rozpatrywać krok po kroku konfliktowe linijki, wybieramy opcję Merge…

Teraz możemy wybierać która wersja kodu, krok po kroku, ma znaleźć się w naszym repozytorium. Pierwsza kolumna jest to (w naszym przypadku) kod znajdujący się na masterze. Ostatnia (trzecia) kolumna jest to kod, który znajduje się na scalanym branch’u (change_2). Podwójne strzałki (>> lub <<) znajdujące się między kolumnami, wstawią nam kod z wybranej kolumny do kolumny środkowej, która jest jednocześnie końcowym rezultatem, który znajdzie się w pliku po zakończeniu scalania. Strzałkami możemy dodać jedną ze zmian, obie lub żadnej, tu mamy dowolność. Każda z konfliktowych zmian będziesz tu rozpatrywał osobno i każda z nich będzie posiadała osobny znacznik dodania (>>).

Aby zakończyć proces rozwiązywania konfliktów i zarazem scalania wybierz przycisk Apply. W ten sposób wybrane zmiany znajdą się scalanym pliku. Należy pamiętać, że zmiany te będą po tym procesie jedynie w lokalnej wersji repozytorium. W tym momencie należy przeprowadzić proces wciągania zmian na zdalne repozytorium, aby tam się znalazły zmiany ze scalania.

Jak widać, konflikty brzmią dość strasznie z nazwy, ale nie muszą być takimi na co dzień, jeśli tylko będziemy używać narzędzi, które pomogą nam w ich rozwiązywaniu.