Git jest git: Rozwiązywanie konfliktów

Podczas pracy z systemem kontroli wersji czasem zdarza się, że nasz pull request ma konflikty. Konflikty powstają gdy ten sam plik został zmieniony w różny sposób w tym samym miejscu w obu scalanych ze sobą branchach. Wpis ten pokazuje jak ja radzę sobie z konfliktami w systemie Git.

TL;DR: Na końcu wpisu znajduje się skrócona instrukcja.

Rozwiązywanie konfliktów

1. Aktualizacja lokalnego brancha

W pierwszej kolejności należy uaktualnić branch z którym jesteśmy w konflikcie i do którego chcemy scalić feature branch wystawiając pull request.

git fetch origin develop:develop

2. Aktualizacja feature brancha

Uaktualnić feature branch można na dwa sposoby – wykonując merge lub rebase. Ja stosuję drugie rozwiązanie. Przy tym podejściu nie powstanie dodatkowy merge commit, który łączy historie obu branchy (zawsze to jeden commit mniej w historii).

git rebase develop

Podczas aktualizacji zostaniemy poinformowani o konfliktach, które właśnie próbujemy rozwiązać. W tym momencie należy wykonać instrukcję mergetool, aby uruchomić narzędzie graficzne do rozwiązywania konfliktów. To jest ten moment kiedy przy pomocy mergtoola decydujemy, które kawałki kodu są właściwe. Tym samym rozstrzygamy, który kod chcemy lub nie w pliku wynikowym na koniec scalania ze sobą branchy. Moim mergetoolem jest KDiff3, opisałem to narzędzie w tym poście.

Na koniec, gdy już rozwiążemy wszystkie konflikty, należy wykonać rebase --continue, aby przejść dalej do następnego commita, w którym mogą lub nie wystąpić następne konflikty. Pamiętajmy również o tym, że możemy wykonać rebase --skip, aby ominąć commit oraz rebase --abort, aby anulować proces aktualizacji.

3. Build projektu (opcjonalne)

Na tym etapie dobrą praktyką jest próba zbudowania projektu. Ma to na celu potwierdzić, że podczas rozwiązywania konfliktów nie usunęliśmy wymaganego kodu, nie dodaliśmy kodu który jest niekompletny, niewłaściwy.

4. Wypchanie zmian

Na koniec należy wypchnąć zmiany do zdalnego repozytorium. Stosując rozwiązanie z rebase, należy wykonać tzw. force pusha.

git push -f origin feature/SS-32


Skrócona instrukcja

-- update local develop branch
git fetch origin develop:develop

-- update feature branch by local develop
git rebase develop

-- force push to push changes on remote feature branch (without commit!)
git push -f origin feature/SS-24

Podbij ↑

One thought on “Git jest git: Rozwiązywanie konfliktów

  1. Pingback: Dyndające przecinki, czyli notacja przecinkowa | Łukasz Kurzyniec

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *