10 Minutowy Przewodnik Po Podstawach GITa – rozwiązywanie konfliktów

W poprzednim wpisie poznaliśmy potęgę prowadzenia prac na osobnych gałęziach i ich późniejsze łączenie, co w GIT realizowane jest poprzez komendę git merge. Takie prace na niezależnych gałęziach niesie ze sobą ryzyko występowania konfliktów, kiedy to zmiany zostały naniesione dla tego samego kawałka kodu.

BRANCH

Przygotujmy nasze repozytorium, tak, aby taki konflikt miał miejsce. W tym celu stwórzmy branch o nazwie dev poleceniem git branch dev. Jak widać na poniższym, samo utworzenie gałęzi automatycznie nas do niego nie przepina (symbol gwiazdki przy nazwie brancha informuje, na którym aktualnie się znajdujemy), więc aby wprowadzić zmiany na gałęzi dev musimy się na niego przepiąć.

Utworzenie gałęzi dev

Wiemy już jak to się robi, bo poznaliśmy już wcześniej polecenie git checkout.

Zmiana gałęzi na dev
Zmiany w hello.sql x2

Skoro jesteśmy na branchu dev, zmieńmy coś w pliku hello.sql i zapiszmy zmiany. Kolejność poleceń jest nam już znana, a przedstawia się następująco:

Zmiany w pliku hello.sql w gałęzi dev
Zmiany w pliku hello.sql w gałęzi dev

Zróbmy teraz tą samą akcję, zmieniając plik hello.sql w gałęzi głównej master, do której wcześniej musimy się przepiąć. Kolejność poleceń w tym przypadku wygląda następująco:

Zmiany w pliku hello.sql w gałęzi głównej master
Zmiany w pliku hello.sql w gałęzi głównej master

To, jak prezentuje się nasze repozytorium po wszystkich działaniach obrazuje poniższa grafika. Kolejność snapshota z gałęzi master i gałęzi dev są równorzędne, mimo że zostały przedstawione jedno obok drugiego. Istotne jest jednak to, że złączenie może mieć miejsce tylko z poziomu gałęzi master.

Struktura naszego repozytorium
MERGE

Skoro już się w nim znajdujemy to złączmy nasze zmiany poleceniem git merge dev, gdzie dev to oczywiście nazwa naszej drugiej gałęzi.

Polecenie merge i konflikt
Polecenie merge i długo wyczekiwany konflikt
First CONFLICT

I stało się. W edytorze, którego używamy widać doskonale, gdzie konflikt ma miejsce. Między znacznikami <<<<<<<<>>>>>>>> znajduje się treść, którą trzeba przeedytować, aby merge mógł mieć miejsce.

Ale jak to zrobić, zapewne padnie pytanie? Nie ma automatu, który zrobi to lepiej niż my sami. Łopatologicznie z poziomu ulubionego edytora tekstowego, linijka po linijce decydujemy, co zostaje, a z czego rezygnujemy. Ja zdecydowałem się być wiecznie młody 🙂

Po naniesieniu wszystkich zmian nie pozostaje nam nic innego jak dodanie i zapisanie zmian. A co z gałęzią dev, wykonaliśmy przecież polecenie merge? Dev istnieje i do czasu usunięcia go poleceniem git branch -D dev będziemy mogli z niego korzystać i na nim pracować.

Rozwiązanie konfliktu
Rozwiązanie konfliktu

I to właściwie tyle w tej części przewodnika. Nauczyliśmy się tworzyć konflikty i je rozwiązywać, jak również okiełznać to, w której gałęzi aktualnie się znajdujemy.


Co jeszcze może Cię zainteresować:


Dodatkowe materiały:

https://youtu.be/mxDN0rYQyGA

///