BoardGamesNook · Git · Programowanie

Merge w GitBashu

Załóżmy, że mamy jakiś branch master_xmpl, który jest głównym branchem naszego projektu.

history0.JPG

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.

branch1.JPG

Autor2: zmiany na branch2

Zmiany na tym branchu polegały na dodaniu sprawdzenia, czy obiekt nie jest nullem.

branch2.JPG

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?

br1merge.JPG

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?

br2merge.JPG

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”.

merge.JPG

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.

3 myśli na temat “Merge w GitBashu

  1. 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.

    Polubione przez 1 osoba

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Connecting to %s