10 Minutowy Przewodnik Po Podstawach GITa #7 – 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ąć.
Wiemy już jak to się robi, bo poznaliśmy już wcześniej polecenie git checkout.
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:
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:
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.
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.
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ć.
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.
Szymon