Załóżmy, że mamy jakiś branch master_xmpl, który jest głównym branchem naszego projektu.
Wyobraźmy sobie, że 2 osoby w tym samym czasie pracują nad różnymi funkcjonalnościami. Każda z nich utworzyła swój branch za pomocą komendy checkout z parametrem b.
git checkout -b branch1
Dla przykładu będą to branch1 dla osoby autor1 i branch2 dla osoby autor2.
Autor1: zmiany na branch1
Zmiany na tym branchu polegały na zmianie nazwy parametru metody w UserController.
Autor2: zmiany na branch2
Zmiany na tym branchu polegały na dodaniu sprawdzenia, czy obiekt nie jest nullem.
Problem
Autor1 i autor2 zmieniali ten sam plik, a nawet tę samę metodę. Co się stanie, gdy będą chcieli wrzucić swoje zmiany do głównego brancha używając popularnej komendy merge?
Autor1: merge branch1 do master
Najpierw autor1 zmieni branch na branch główny master_xmpl za pomocą komendy:
git checkout master_xmpl
A następnie zmerguje zmiany z branch1:
git merge branch1
Jaki otrzyma wynik?
Wszystko poszło ok.
Autor2: merge branch2 do master
Autor2 będzie chciał zrobić to samo. Wpisze komendę:
git merge branch2
I nie działa! Jaki jest wynik?
Wystąpił konflikt, który należy ręcznie rozwiązać na poziomie kodu. Autor musi więc ręcznie połączyć zmiany. Zmienia kod, więc czego wynikiem będzie nowy commit. Często commity tego typu z braku pomysłu mają niewiele mówiący komunikat „fix merge issue”.
Po wrzuceniu commita w fixem wszystko działa poprawnie.
Kilka słów ode mnie
Osobiście nie przepadam za powyższym rozwiązaniem. Wiele commitów mergujących zaciemnia historię. Do tego niepoprawny merge (np. przez pominięcie części zmian) może spowodować, że kod nie będzie działał prawidłowo. Wykrycie tego problemu może czasem zająć dłuższą chwilę. Przecież autor1 sprawdził swoje zmiany na głównym branchu. Autor2 również sprawdził swoje zmiany na głównym branchu. Mógł nie wiedzieć, jakie zmiany wprowadził autor1, a nawet jeśli wiedział, to mógł nie sprawdzić, czy działają poprawnie po wprowadzeniu wszystkich zmian. Powoduje to czasami problemy, których można uniknąć.
Alternatywy
Alternatywą dla powyższego rozwiązania jest np. komenda rebase. Ale o tym napiszę w kolejnym poście.
Podoba Ci się to, co tworzę? Chcesz dostawać informacje o:
– wydarzeniach, które organizuję lub wspieram (np. konferencje, meetupy, webinary)
– inicjatywach, które organizuję lub wspieram (np. GeekWeekWro, DevAdventCalendar)
– moich prelekcjach, kursach i szkoleniach
– wyróżnionych artykułach z mojego bloga
0% SPAMu, 100% informacji! Krótko i na temat.
Programmer-girl Weronika Mularczyk 
Z merge conflict’ami zawsze jest tak, że trzeba sobie radzić różnie, w zależności od kontekstu, tzn. inaczej będziemy poprawiać .edmx’a, a inaczej będziemy sobie radzić właśnie z kodem. Nie ma uniwersalnej metody. Natomiast można ograniczać konflikty poprzez higienę pracy z kontrolą wersji. W małych zespołach jest też łatwiej się dogadać, co kto i gdzie zmienia.
PolubieniePolubione przez 1 osoba
Jak najbardziej 😉
PolubieniePolubienie
Pingback: Zmiana historii: rebase w GitBashu – programmer-girl