Wątek przeniesiony 2022-02-22 09:42 z Webmastering przez Riddle.

Niechciane konflikty przy mergowaniu

0

Witam,

Kolega stworzyl nowa galez branch1 z master i puscil do niej swoje zmiany. Generalnie, my puszczamy do produkcji pojedyncze galezie, nie jeden duzy feature. Teraz ja stworzylem kolejne 2 galezie z gelezi branch1. Kolega puscil live swoja galez branch1 i pojawil sie problem z konliktami. Oczywiscie zrobilem pull i zmergowalem master galez do moich dwoch galezi. I wszedzie wyskoczyly konflikty, w moich 2 galeziach. Git uwaza, ze moje zmiany to sa konflikty, a nie zmiany. Zamiast normalnie nadpisac i zmergowac, to git praktycznie wszedzie, gdzie napisalem zmiany, wywala mi konflikty. I jak usunalem po koledze dwa pliki json to dodaje je od razu, nawet nie zglasza, ze widzi konflikt.

Jakis pomysl czemu tak sie dzieje? Czemu Git nie aplikuje zmian, tylko zglasza konflikty?

9

No dzieje się tak, dlatego że widocznie nierozumiecie w jaki sposób git łączy drzewa. Najpierw powiem Ci co mi się wydaje że się u was stało; a potem napiszę co według mnie powinniście zrobić.

Po zerowe; najpewniej na dwóch gałęziach istnieją albo zduplikowane commity, bo ktoś z was zrobił git rebase; albo macie niepoprawne końcówki linii, typu jeden z was ma CRLF a inny LF; albo wprowadziliście po prostu niekompatybilne zmiany na dwóch branachach.

Konflikt to nic złego; to po prostu komunikat z gita, że nie jest w stanie automatycznie, bezpiecznie połączyć zmiany i prosi Cię byś zrobił to sam.

Po pierwsze, git pull to nic innego jak zrobienie najpierw git fetch a potem git merge na branchu z którego jesteś. (Czyli jak jesteś na branchu master to git pull zrobi git merge origin/master). Chyba że ustawiłeś w ustawieniach że default to rebase, w co wątpię.

Dwa, jak git łączy gałęzie:

  • Jeśli dwie gałęzie wyszły z tej samej bazy (z tego samego wspólnego commita), i edytowały tylko różne pliki (np Ty edytowałeś plik A.json a kolega B.json), to takie gałęzie są łączone bez problemu
  • Jeśli na dwóch gałęziach jest owszem edytowany ten sam plik (czyli zarówno Ty jak i kolega edytowaliście plik A.json), ale w taki sposób że te zmiany sobie "nie wadzą", typu Ty edytowałeś coś na górze, a on coś na dole to też jest git.
  • Jeśli wprowadziliście dokładnie takie same zmiany w pliku, tak że wynikowy plik jest taki sam, to też git powinien połączyć bez problemu.
  • Jest jeszcze kilka innych case'ów gdzie git sam połączy takie pliki

Jeśli natomiast wprowadziliście niekompatybilne zmiany ze sobą, np Ty dodałeś taką treść:

{"key": "123"}

a kolega taką:

{"key": "456"}

no to oczywiście git wtedy powie: "Nie wiem jak połączyć te pliki", i zobaczysz konflikt. Większość ludzi tutaj mówi: "Aaaa, git powinien wziąć tą późnijeszą", albo "Git powinien wziąć moją", bla bla. pierdoły.

To co możesz zrobić, to:

  • Albo rozwiązać konflikt, czyli ustalić która wersja ma być, potem zrobić git add . i git merge --continue
  • Albo użyć podczsa merga przełącznika -X theirs albo -X yours żeby git wiedział którą wersję ma brać podczas merge'a.
  • Albo upewnić się czy wasze zmiany na pewno są kompatybilne i czy na pewno da się je połączyć, bo jeśłi kumpel zrobił rebase to nie połączysz ich tak "po prostu".

Bo git nie jest cudotwórcą ani jasnowidzem i nie domyśli się jaki efekt chcesz osiągnąć.

Jeśli chcesz dokładniejszej rady musiałbyś pokazać screena z history gitowej, żeby dało Ci się powiedzieć co możesz zrobić.

1

Szklana kula mówi ze kolega mergując swój branch do mastera zrobił squash (albo jakieś rebase) czyli zmienił historię swojego brancha, przez co master nijak się ma do tego co ty teraz masz u siebie. Git patrzy na listę commitów w branchu i dopasowuje po tym zmiany. Jeśli kolega zrobił squash to w masterze jego zmiany są władowane w jeden commit, podczas gdy u ciebie te zmiany są rozsiane na N commitów. Z punktu widzenia gita ten zbiorczy commit z mastera i te commity które ty masz u siebie konfliktują bo modyfikują te same fragmenty kodu (z oczywistych względów).

Oczywiscie zrobilem pull i zmergowalem master galez do moich dwoch galezi

Nie wiem co w tym oczywistego, bo ja jednak zwykle robie w takiej sytuacji rebase żeby to jakoś wyglądało (po rebase twoje commity z danego brancha są na górze).

W ogóle odbicie brancha od brancha a potem mergowanie ich w odwrotnej kolejności to słaby plan i trochę nie dziwi mnie że się to posypało, szczególnie jak ktoś zrobił squasha.

1 użytkowników online, w tym zalogowanych: 0, gości: 1