Praca z GITem — w którą stronę robić merge? :)

Podczas pacy programisty GIT może być zarówno zbawieniem jak i utrapieniem. Ja przychylam się do tego pierwszego stwierdzenia, ale początkujący programiści są często innego zdania :)

Ostatnio natknąłem się na dość ciekawy problem i zarazem jego rozwiązanie. Załóżmy, że tworzymy projekt według modelu git flow i naszą nową feature na branch’y feature/new-feature chcemy zmegrować do branch’y develop, która wymaga pull requesta na potrzeby np. code review. Jednym zdaniem musimy pozbyć się potencjalnych konfliktów miedzy branch’ami przed zrobieniem PR.

Pierwszym rozwiązaniem, które przychodzi do głowy jest domergowanie developa do naszej nowej feature/new-feature, rozwiązanie konfliktów i PR.

Ostatnio jednakże zapytano mnie “Ale jak to? Przecież chcieliśmy robić merge do developa a nie z developa do feature — to nie ten kierunek!”

Otóż wygląda na oto, że nieoczywistym jest to, że merge jest poleceniem, którego wynik jest zawsze identyczny, niezależnie od tego, z której branchy, na którą robimy merge. Zależy tylko od tego, które dwie branch’e mergujemy i od ich wspólnego przodka (plus sposobu rozwiązania konfliktów)!

Kolejnym problemem okazało się to, że zmiany poczynione na developie w międzyczasie, kiedy my byliśmy zajęci rozwijaniem naszej branch’y feature/new-feature, o ile nie ma w nich konfliktów, będą automatycznie połączone z tym co zrobiliśmy na naszej nowej branch’y! Czyli — ktoś na developie może napisać coś, co nam zepsuje np. nasze style CSS, bo ten ktoś zmodyfikował ich arkusz, oddając kolejne reguły na końcu — nadpisując nasze! Oczywiście, jest to możliwe, bo merge, jak sama nazwa wskazuje, łączy zmiany, i “nowsza”/”nasza” wersja nie ma “pierwszeństwa” :) Jak temu zapobiec? Zrobić commita po merge’u naprawiającego niespójności, albo wykonać merge z opcją --no-commit , która spowoduje przerwanie nawet merge’a bez konfliktów, udostępni mam zmiany w naszej przestrzeni roboczej (working copy) i będziemy mogli je jeszcze zmodyfikować zanim zcommitujemy wszystko na raz.

Jest też sposób na to żeby zawsze robić merge w “dobrym kierunku”, czyli do developa (na którego bezpośrednio zapisywać nie możemy — wymagany PR). Oczywiście efekt będzie ten sam, ale może niektórym wyklarować sprawę. Sposób wygląda tak:

  • przechodzimy na developa
  • tworzymy z niego kolejną (trzecią) branch o nazwie np. merge
  • na nową branch, którą wskazuje na dokładnie tą samą wersję plików co develop, możemy już zapisywać, więc:
  • przechodzimy na branch’y merge i robimy merge naszej branch’y do niej
  • rozwiązujemy konflikty
  • z branch’y merge robimy PR do developa
  • KONIEC :)
One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.