Autor Wątek: Git, commitowanie poprawki do zmergowanego brancha  (Przeczytany 2507 razy)

Offline ShadowDancer

  • Redaktor

# Marzec 23, 2015, 13:58:51
Cześć,
mam następujący problem - był sobie branch i w pewnym momencie został on zmergowany do origina. Ponieważ ten merge był spory (dużo konfliktów), chciałbym scommitować poprawkę na brancha, ale już na tą zmergowaną wersję. Jaki jest najlepszy sposób zrobienia tego? Wydaje mi się, że powinienem zrobić tak:
-przełączyć się na origina
-zacommitować zmiany na origina
-przysunąć pointer brancha na najnowszy commit
git update-ref -m "reset: Reset <branch> to <new commit>" refs/heads/<branch> <commit>


Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline ByerN

  • Użytkownik

# Marzec 23, 2015, 15:58:01
Witaj,
Najlepiej pullować główną gałąź do pobocznej i dopiero tak zmergowaną wypychać do głównej. W ten sposób rozwiązujesz konfilkty na swoim branchu i wszystko jest dość klarowne (no i można stosować pull requesty z jakimś systemem zarządzania gitem).

Ja bym zmergował główną gałąź do tej Twojej i wypchnął.

Takie rozwiązanie będzie ok? Sprawdź sobie, najwyżej cofniesz zmiany.

Jak będziesz często tak robił, to zmniejszyj liczbę konfliktów. Jak nic nie robiłeś i chcesz najnowszą wersję brancha na którym robisz to zrób pull z rebasem zamiast mergem. Ja używam Git Extensions i nie korzystam z konsoli, więc nie podam Ci konsolowych komend. :P
« Ostatnia zmiana: Marzec 23, 2015, 16:02:36 wysłana przez ByerN »

Offline Xender

  • Użytkownik

# Marzec 23, 2015, 16:08:27
Jeśli tego nie pushnąłeś, to rebase -i --preserve-merges i pofixupować commity które trzeba.
Można amendować merge commity bez problemu, fixupować chyba też.

Tak jest najczyściej, bo w historii nie zostają wadliwe commity poprawiane potem następnymi.

Najlepiej pullować główną gałąź do pobocznej i dopiero tak zmergowaną wypychać do głównej.
Miałem nadzieję, że to skrót myślowy, ale po drugiej część posta nie sądzę, więc...

Najlepiej nic nie pullować.
Pull to skrót na fetch + merge.

Polecam fetch + rozejrzenie się po repo, co tak właściwie zostało sfetchowane (konieczny krok przed przechodzeniem dalej!) + merge / rebase / ratowanie się z rebase na upstreamie / ??? wg. potrzeb.
Ślepe pullowanie to proszenie się o pokićkaną historię.
« Ostatnia zmiana: Marzec 23, 2015, 16:12:56 wysłana przez Xender »

Offline ByerN

  • Użytkownik

# Marzec 23, 2015, 16:34:16
Miałem nadzieję, że to skrót myślowy, ale po drugiej część posta nie sądzę, więc...

Najlepiej nic nie pullować.
Pull to skrót na fetch + merge.

Polecam fetch + rozejrzenie się po repo, co tak właściwie zostało sfetchowane (konieczny krok przed przechodzeniem dalej!) + merge / rebase / ratowanie się z rebase na upstreamie / ??? wg. potrzeb.
Ślepe pullowanie to proszenie się o pokićkaną historię.

Jeżeli nie przejmujesz się tym by historia była przejrzysta, tylko chcesz łatwo i szybko zapewnić sobie kontrolę wersji, to zrób jak mówię. :P W sieci jest pełno artykułów mówiących o dwóch podejściach i różnicy między nimi (Nastawione na merge lub nastawione na rebase).

Przykład (tak na szybko):
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/workflow-walkthrough

Nieumiejętne rebase'y potrafią prowadzić do problemów częściej niż zwykły pull.

Offline ShadowDancer

  • Redaktor

# Marzec 23, 2015, 17:38:10
Tak wygląda repo, dorysowana zielona strzałka to commit, który chcę dodać (i chcę, aby branch XXX wskazywał na ten commit). Merge XXX był bardzo bolesny i nie chcę go powtarzać.


Jak rozumiem sugerujecie rebase brancha na commit oznaczony czerwonym kółkiem - ale czy to nie spowoduje konieczności ponownego merge? Wszystko co siedzi w repo (i na serwerze) jest ok, jednak wolałbym kontynuować branch XXX ze względu na zachowanie historii.
« Ostatnia zmiana: Marzec 23, 2015, 17:40:01 wysłana przez ShadowDancer »

Offline Xion

  • Redaktor
    • xion.log

  • +3
# Marzec 23, 2015, 18:24:24
Jeśli XXX to zwykły feature branch, to czemu po prostu nie merge'nać mastera z powrotem, albo zrobić wręcz cherry-pick fiksa? No chyba że kręci cię orwellowskie przekręcanie historii, to wtedy baw się z tym co sugeruje Xender :)

Offline Xender

  • Użytkownik

# Marzec 23, 2015, 19:07:22
@ShadowDancer - Sugeruję fixup commita, w którym został popełniony błąd.

rebase -i --preserve-merges --autosquash:
http://explainshell.com/explain?cmd=git+rebase+-i+--preserve-merges+--autosquash

Wbrew ostrzeżeniom, połączenie -i z -p w celu fizupowania/squashowania commitów jest bezpieczne.
To, na co przy tej kombinacji trybów może się zepsuć, to zamiana commitów miejscami - generalnie nie Twój przypadek.
http://git-scm.com/docs/git-rebase

Nieumiejętne rebase'y potrafią prowadzić do problemów częściej niż zwykły pull.
To trzeba je robić umiejętnie.
Jak uczyłem się gita, to opanowałem rebase zanim opanowałem merge.
To nie jest tak, że któreś jest trudniejsze.

Aha, reflog przyjacielem. ;)

Offline ShadowDancer

  • Redaktor

# Marzec 23, 2015, 20:24:57
@Xion
Mergować mastera z powrotem w co? Ja jeszcze nie mam commita oznaczonego jako "fix blah blah blah" i zastanawiam się jak elegancko to rozegrać. Sugerujesz merge origina z branch'em i potem commit na tego branch'a?


@Xender
Ja nie chcę zmieniać niczego w branch'u, po prostu go kontynuować.

Offline ByerN

  • Użytkownik

# Marzec 24, 2015, 08:41:39
Ja nie jestem jakimś guru gita akurat więc wydaje mi się, że Xender ma całkowitą rację jeżeli chodzi o poprawność jego rozwiązania. :P Rozwiązanie, które podałem ja (i pokrewnie Xion) jest proste i wystarczające, ale lekko zaśmieca historię.

@Xion Jak dla mnie to cherry-picka lepiej używać tylko w ostateczności. W tym przypadku powinno wystarczyć wyjście, o którym wcześniej była mowa.

Offline Xender

  • Użytkownik

# Marzec 24, 2015, 12:01:22
Cherry-pick ma tę przypadłość, że wspólne zmiany nie będą miały wspólnego commita (merge-base).
To się może odbić

Dopóki zmiany od merge-base po obu stronach są identyczne, nie ma problemu.
Ale gdy po zpickowanym commicie, możliwie wiele commitów później, po którejkolwiek ze stron zostaną wprowadzone inne zmiany w tych samych hunkach, wtedy będzie konflikt.

3-way merge dla zpickowanych hunków efektywnie zdegraduje się do 2-way merge, bo w merge-base zmian zpickowanych z jednego brancha na drugi (a potem zmienionych późniejszym commitem) nie będzie w ogóle.

Jeśli koniecznie pickować, to z -x.
Chociaż jeśli commit, który pickujemy nigdy nie ma zostać pushnięty do repo, do którego pushnięty będzie commit powstały w wyniku picka, wtedy -x zaśmieca commit message...
W takiej sytuacji chyba użyłbym git-notes.

Offline ShadowDancer

  • Redaktor

# Marzec 24, 2015, 23:51:34
Dzięki za rady ;)