TL;DR

Przepływ pracy git rebase nie chroni Cię przed osobami, które źle rozwiązują konflikty lub są przyzwyczajone do przepływu pracy SVN, jak sugerowano w unikanie katastrof Git: Krwawa Historia . To tylko sprawia, że rozwiązywanie konfliktów jest dla nich bardziej żmudne i utrudnia powrót do zdrowia po złym rozwiązaniu konfliktu. Zamiast tego użyj diff3, aby nie było to takie trudne.

Rebase workflow nie jest lepszy dla konfliktu postanowienie!

Jestem bardzo pro-rebase do czyszczenia historii. Jeśli jednak dojdzie do konfliktu, natychmiast przerywam rebase i wykonuję połączenie! to naprawdę dobija mnie, że ludzie zalecają przepływ pracy rebase jako lepszą alternatywę dla przepływu pracy merge do rozwiązywania konfliktów (o co dokładnie chodziło w tym pytaniu).

Jeśli dojdzie do" all To hell "podczas scalania, przejdzie do" all to hell "podczas rebase' u, i potencjalnie będzie to dużo więcej piekła! Oto dlaczego:

Powód # 1: rozwiązywanie konfliktów raz, zamiast raz dla każdego commit

Podczas rebase 'u zamiast scalania, będziesz musiał rozwiązywać konflikty do tylu razy, ile masz commitów do rebase' u, dla tego samego konfliktu!

Prawdziwy scenariusz

Rozgałęziam się z master, aby refaktorować skomplikowaną metodę w gałęzi. Moja praca refaktoryzacyjna składa się z 15 commitów w sumie, gdy pracuję nad refaktoryzacją i uzyskuję recenzje kodu. Część refaktoryzacji polega na naprawieniu mieszane tabulatory i spacje, które były obecne w master przed. Jest to konieczne, ale niestety będzie to sprzeczne z każdą zmianą dokonaną później w tej metodzie w master. Oczywiście, gdy pracuję nad tą metodą, ktoś dokonuje prostej, legalnej zmiany do tej samej metody w gałęzi master, która powinna być scalona z moimi zmianami.

Kiedy nadszedł czas, aby połączyć moją gałąź z powrotem z master, mam dwie opcje:]}

Git merge: Mam konflikt. Widzę zmiany, które wprowadzili do master i połączyli je z (produktem końcowym) moją gałęzią. Załatwione.

Git rebase: Mam konflikt z moim pierwszym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moimdrugim commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim trzecim commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim czwartym commit. Rozwiązuję konflikt i kontynuować rebase. Mam konflikt z moim piątym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim szóstym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim siódmym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim ósmym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim dziewiątym commit. I resolve konflikt i kontynuować rebase. Mam konflikt z moim commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moimdwunastym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim trzynastym commit. Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim czternastym / align = "left" / Rozwiązuję konflikt i kontynuuję rebase. Mam konflikt z moim commit. Rozwiązuję konflikt i kontynuuję rebase.

Z wszystkimi dodatkowymi rozwiązaniami konfliktu, które musisz zrobić, Zwiększa to po prostu możliwość, że popełnisz błąd . Ale błędy są w porządku w git, ponieważ można cofnąć, prawda? Z wyjątkiem oczywiście...

Powód # 2: z rebase, nie ma cofnięcia!

Myślę, że wszyscy możemy się zgodzić, że rozwiązywanie konfliktów może być trudne, a także, że niektórzy ludzie są bardzo źle. Może być bardzo podatny na błędy, dlatego jest tak świetny, że git ułatwia cofnięcie!

Kiedy połączysz gałąź, git tworzy commit scalający, który można odrzucić lub zmienić, jeśli rozwiązanie konfliktu pójdzie źle. Nawet jeśli już przesunąłeś zły commit merge do publicznego / autorytatywnego repo, możesz użyć git revert, aby cofnąć zmiany wprowadzone przez commit merge i ponownie poprawnie scalić w nowym commicie merge.

Kiedy rebase Oddział, w przypadku, gdy rozwiązanie konfliktu jest źle zrobione, masz przerąbane. Każdy commit zawiera teraz złe połączenie i nie możesz po prostu ponowić rebase*. W najlepszym razie musisz wrócić i zmienić każdy z tych zmian. To nie jest zabawne.

Po zmianie bazy nie można określić, co pierwotnie było częścią commitów, a co zostało wprowadzone w wyniku złego rozwiązywania konfliktów.

_{*można cofnąć rebase, jeśli można wykopać stare refy z wewnętrzne logi Gita, lub jeśli utworzysz trzecią gałąź, która wskazuje na ostatni commit przed zmianą rozmiaru.}

Uwolnij się od rozwiązywania konfliktów: użyj diff3

Weźmy na przykład ten konflikt:

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

Patrząc na konflikt, nie można powiedzieć, co każda gałąź zmieniła lub jakie były jej intencje. Jest to moim zdaniem największy powód, dla którego rozwiązywanie konfliktów jest mylące i trudne.

Diff3 na ratunek!

git config --global merge.conflictstyle diff3

Kiedy używasz diff3, każdy nowy konflikt będzie miał trzecią sekcję, połączonego wspólnego przodka.

<<<<<<< HEAD
TextMessage.send(:include_timestamp => true)
||||||| merged common ancestor
EmailMessage.send(:include_timestamp => true)
=======
EmailMessage.send(:include_timestamp => false)
>>>>>>> feature-branch

Najpierw zbadaj połączonego wspólnego przodka. Następnie porównaj każdą ze stron, aby określić intencje każdej gałęzi. Możesz zobaczyć, że HEAD zmienił EmailMessage na TextMessage. Jego celem jest zmiana klasy używanej do TextMessage, przekazując te same parametry. Możesz również zobaczyć, że intencją feature-branch jest podanie false zamiast true dla opcji: include_timestamp. Aby połączyć te zmiany, połącz intencje

TextMessage.send(:include_timestamp => false)

Ogólnie:

W 2007 roku, po raz pierwszy w historii, w Polsce, w 2008 roku, w Polsce i na świecie, w 2009 roku, w Polsce i na świecie, w 2009 roku, w Polsce i za granicą.]}
1. zastosuj tę prostą zmianę do wersji kodu innej gałęzi, tak aby zawierała zarówno prostszą, jak i bardziej złożoną zmianę
2. Usuń wszystkie sekcje kodu konfliktu, inne niż ta, którą właśnie połączyłeś ze sobą zmiany]}

Alternate: Resolve poprzez ręczne zastosowanie zmiany gałęzi

Wreszcie, niektóre konflikty są straszne do zrozumienia nawet w przypadku diff3. Dzieje się tak zwłaszcza wtedy, gdy diff znajduje wspólne linie, które nie są semantycznie wspólne (np. obie gałęzie miały puste linie w tym samym miejscu!). Na przykład, jedna gałąź zmienia wcięcie ciała klasy lub zmienia kolejność podobnych metod. W takich przypadkach lepszą strategią rozdzielczości może być zbadanie zmiany po obu stronach połączenia i ręczne zastosowanie różnicy do inny plik.

Przyjrzyjmy się, jak możemy rozwiązać konflikt w scenariuszu, w którym łączenie origin/feature1, gdzie lib/message.rb konfliktuje.

1. Zdecyduj, czy nasza aktualnie sprawdzona gałąź (HEAD, lub --ours) lub gałąź, którą łączymy (origin/feature1, lub --theirs) jest prostszą zmianą do zastosowania. Użycie Diffa z potrójną kropką (git diff a...b) pokazuje zmiany, które zaszły na b od jego ostatniej rozbieżności z a, lub innymi słowy, porównaj wspólny przodek a i b z b.

   git diff HEAD...origin/feature1 -- lib/message.rb # show the change in feature1
   git diff origin/feature1...HEAD -- lib/message.rb # show the change in our branch
   

2. Sprawdź bardziej skomplikowaną wersję pliku. Spowoduje to usunięcie wszystkich znaczników konfliktu i użycie wybranej strony.

   git checkout --ours -- lib/message.rb   # if our branch's change is more complicated
   git checkout --theirs -- lib/message.rb # if origin/feature1's change is more complicated
   

3. Po sprawdzeniu skomplikowanej zmiany, wyciągnij różnicę prostszej zmiany (patrz krok 1). Zastosuj każdą zmianę z tego rozróżnienia do pliku kolidującego ze sobą.

W moim workflow, rebase jak najwięcej (i staram się to robić często. Nie pozwalając na gromadzenie się rozbieżności drastycznie zmniejsza ilość i nasilenie kolizji między gałęziami).

Jednak nawet w przepływie pracy opartym głównie na rebase jest miejsce do łączenia.

Przypomnijmy, że merge faktycznie tworzy węzeł, który ma dwoje rodziców. Teraz rozważ następującą sytuację: mam dwie niezależne brance funkcji A i B, a teraz chcę rozwijać rzeczy na temat funkcji gałąź C, która zależy zarówno od A jak i B, podczas gdy a i B są sprawdzane.

To, co robię, jest następujące:

1. Utwórz (i sprawdź) gałąź C na szczycie A.
2. Połącz z B

Teraz gałąź C zawiera zmiany zarówno z A jak i z B i mogę na niej dalej rozwijać. Jeśli zrobię jakąś zmianę Na A, to zrekonstruuję Wykres gałęzi w następujący sposób:

1. Utwórz gałąź T na nowej górze A
2. Połącz T z B
3. rebase C na T
4. Usuń gałąź T

W ten sposób mogę utrzymywać dowolne wykresy gałęzi, ale robienie czegoś bardziej skomplikowanego niż opisana powyżej sytuacja jest już zbyt skomplikowane, biorąc pod uwagę, że nie ma automatycznego narzędzia do robienia rebasingu, gdy zmieni się rodzic.

Nie używaj git push origin -- mirror w niemal każdych okolicznościach.

Nie pyta, czy jesteś pewien, że chcesz to zrobić, i lepiej się upewnij, ponieważ usunie wszystkie zdalne gałęzie, które nie znajdują się na twoim lokalnym polu.

Http://twitter.com/dysinger/status/1273652486

Mam jedno pytanie po przeczytaniu twojego wyjaśnienia: czy to możliwe, że nigdy nie zrobiłeś

git checkout master
git pull origin
git checkout my_new_feature

Przed wykonaniem 'Git rebase/merge master' w gałęzi feature?

Ponieważ twoja gałąź master nie będzie aktualizowana automatycznie z repozytorium Twojego znajomego. Musisz to zrobić git pull origin. Czyli może zawsze zmieniałbyś dane z nigdy nie zmieniającej się lokalnej gałęzi master? A potem nadchodzi czas push, naciskasz w repozytorium, które ma (lokalne) commity, których nigdy nie widziałeś i w ten sposób naciśnięcie nie powiedzie się.

W twojej sytuacji myślę, że twój partner ma rację. To, co jest miłe w rebasingu, to to, że dla outsidera twoje zmiany wyglądają tak, jakby wszystkie miały miejsce w czystej sekwencji same w sobie. Oznacza to

• twoje zmiany są bardzo łatwe do przejrzenia
• możesz nadal tworzyć ładne, małe commity, a mimo to możesz upubliczniać zestawy tych commitów (łącząc je w master) na raz
• kiedy spojrzysz na publiczną gałąź master, zobaczysz różne serie commitów dla różne funkcje przez różnych deweloperów, ale nie wszystkie będą mieszane

Możesz nadal przenosić swoją prywatną gałąź deweloperską do zdalnego repozytorium w celu tworzenia kopii zapasowych, ale inni nie powinni traktować tego jako" publicznej " gałęzi, ponieważ będziesz się zmieniał. BTW, łatwym poleceniem do tego jest git push --mirror origin .

Artykuł oprogramowanie do pakowania za pomocą Git całkiem nieźle wyjaśnia kompromisy w łączeniu i rebasingu. Trochę inaczej. kontekst ale dyrektorzy są tacy sami - w zasadzie sprowadza się to do tego, czy twoje oddziały są publiczne czy prywatne i jak planujesz zintegrować je z linią główną.

W każdym razie, śledziłem mój przepływ pracy na ostatniej gałęzi, i kiedy próbowałem połączyć go z powrotem do mistrza, wszystko poszło do piekła. Było mnóstwo konfliktów z rzeczami, które nie powinny mieć znaczenia. Konflikty nie miały dla mnie sensu. Zajęło mi to dzień, aby wszystko uporządkować i ostatecznie zakończyło się wymuszonym naciskiem na Zdalnego mistrza, ponieważ mój lokalny mistrz rozwiązał wszystkie konflikty, ale zdalny nadal nie był zadowolony.

W ani Twojej partnerce, ani Twojej sugerowane przepływy pracy w przypadku napotkania konfliktów, które nie miały sensu. Nawet jeśli tak było, jeśli postępujesz zgodnie z sugerowanymi przepływami pracy, to po rozwiązaniu "wymuszone" naciśnięcie nie powinno być wymagane. Sugeruje to, że w rzeczywistości nie połączyłeś gałęzi, do której pchałeś, ale musiałeś wcisnąć gałąź, która nie była potomkiem zdalnego wierzchołka.

W porównaniu do wielu innych systemów kontroli wersji odkryłem, że używanie Gita wymaga mniej walki z narzędziem i pozwala na pracę nad problemami, które są fundamentalne dla Twoich strumieni źródłowych. Git nie wykonuje magii, więc sprzeczne zmiany powodują konflikty, ale powinno to ułatwić pisanie rzeczy poprzez śledzenie rodzicielstwa commitów.

Z tego co zaobserwowałem, git merge ma tendencję do oddzielania gałęzi nawet po połączeniu, podczas gdy rebase następnie merge łączy je w jedną gałąź. Ten ostatni wychodzi o wiele czystszy, podczas gdy w pierwszym, łatwiej byłoby dowiedzieć się, które commity należą do której gałęzi, nawet po połączeniu.

" nawet jeśli jesteś pojedynczym programistą z kilkoma gałęziami, warto nabrać nawyku używania rebase i prawidłowego łączenia. Podstawowy wzór pracy będzie wyglądał następująco:

• Utwórz nową gałąź B z istniejącej gałęzi a

• Dodaj / zatwierdź zmiany w gałęzi B

• Aktualizacje Rebase z gałęzi a

• Scalanie zmian z gałęzi B do gałęzi A "

Https://www.atlassian.com/git/tutorials/merging-vs-rebasing/

W Git nie ma "poprawnego" przepływu pracy. Używaj tego, co pływa Twoją łodzią. Jeśli jednak ciągle pojawiają się konflikty podczas łączenia gałęzi, może powinieneś lepiej koordynować swoje wysiłki z innymi programistami? Wygląda na to, że edytujecie te same pliki. Należy również uważać na słowa kluczowe spacji i subversion (np. "$Id$" i inne).