Git rozdzielił się po rebase

Przebudowałem lokalnie gałąź, która została już przeniesiona.

Git informuje, że mój oddział i pilot rozeszły się i że:

"i mają odpowiednio 109 i 73 różne zatwierdzenia"

Czy wypchnięcie mojej gałęzi rozwiąże ten problem - tj. Czy można się tego spodziewać po rebase?

Kiedy przebudowujesz gałąź, musisz przepisać zatwierdzenia dla każdego zatwierdzenia, które znajduje się powyżej zatwierdzeń w gałęzi, na której ponownie bazujesz. Dzieje się tak, ponieważ jedną z właściwości zatwierdzenia jest jego rodzic (lub rodzice). Kiedy dokonujesz rebase, zmieniasz rodzica najstarszego lokalnego zatwierdzenia w twojej gałęzi - a tym samym zmieniasz skróty zatwierdzeń wszystkich lokalnych zatwierdzeń, ponieważ ta zmiana przenosi się przez zatwierdzenia przejściowo.

Ponieważ już wypchnąłeś gałąź, powinieneś był połączyć się z gałęzią źródłową, zamiast opierać się na niej. Możliwe jest "wymuszenie wypchnięcia" twojej nowej gałęzi (używając -fflagi), ale normalny push nie zadziała, ponieważ integralność historii gałęzi zostanie zakłócona. Jeśli współpracujesz z innymi osobami w tej gałęzi, forsowanie siły jest złym pomysłem, ponieważ spowoduje, że inni współpracownicy będą bardzo zdezorientowani, gdy ich historia nagle się nie zgadza.

TL; DR - Jeśli nie współpracujesz, wypchnij gałąź za pomocą push -f. Jeśli tak, zresetuj gałąź do poprzedniego stanu i zamiast tego scal ją w gałęzi źródłowej.

Wszystkie twoje zatwierdzenia zmieniły identyfikatory, więc dywersja nie jest tak naprawdę rozbieżna.

Aby rozwiązać problem , musisz nadpisać zdalną gałąź:

git push -f origin experiment

http://git-scm.com/book/ch3-6.html

Wyjaśnienie:

Zobacz, jak na tym obrazku C3 nie jest wstawiane jako C3 po rebase, ale jako C3 '. Dzieje się tak, ponieważ nie jest to dokładnie C3, ale ma wszystkie zmiany w kodzie.

Na tym drugim obrazie widać, co widzi rebase, gdy w grę wchodzi pilot, i dlaczego występuje przekierowanie.

W każdym razie, po wykonaniu wymuszonego pchnięcia, powie ci, że wykonał (wymuszoną aktualizację), w tym momencie powinno być dobrze.

Sprawdź link u góry i wyszukaj „git push --force”. Zobaczysz bardziej szczegółowe wyjaśnienie.

Udało mi się odejść od rebase, wykonując następujące czynności:

git checkout mybranch
git pull
git push origin mybranch

Pociągnięcie rozwiązało rozbieżność.

PRZED pociągnięciem

Your branch and 'origin/mybranch' have diverged,
and have 2 and 1 different commit(s) each, respectively.

Wyjście PULL

Scalanie rekurencyjne. mypath / myfile.py | 12 +++++++++++ - 1 plik zmieniony, 11 wstawień (+), 1 usunięcia (-)

PO pociągnięciu

Twoja gałąź wyprzedza „origin / mybranch” o 3 zatwierdzenia.

PO PUSH

mybranch wyprzedza gałąź o 3, ale nadal ma otwartą wiadomość pull request dodaną do historii zatwierdzeń Połącz gałąź mybranch of remote do mybranch

Zakładam, że jest to prawdopodobnie to, co robi pchnięcie siły i nie zweryfikowałem.

Jak powiedzieli inni, unikaj ponownego bazowania, jeśli masz już otwarte żądanie ściągnięcia. Podaję ten przykład jako coś, co zadziałało dla mnie.

Można to naprawić bez pchania siły, przenosząc gałąź docelową do bieżącej gałęzi lokalnej, przełączając się na gałąź docelową, a następnie przekształcając gałąź lokalną w docelową. To się nie różni, ponieważ zmiany, których może brakować, są dodawane i nie trzeba ich już tworzyć. Przykład łatwiejszego wyjaśnienia:

1. główna gałąź jest rozwijana
2. Kupujesz nową funkcję oddziału / doing_stuff
3. Członek zespołu popycha nowe zobowiązanie do rozwoju

Jeśli NIE zaktualizowałeś swojej gałęzi deweloperskiej, wtedy "git checkout develop" && "git rebase feature / doing_stuff" będzie działać poprawnie, ponieważ nie dodano żadnych zatwierdzeń od czasu twojego zamówienia. Jeśli jednak sprawdziłeś program i usunąłeś nowy commit, zobaczysz tę rozbieżność, jeśli spróbujesz zmienić bazę z powodu zobaczenia nowego zatwierdzenia. Łatwym rozwiązaniem bez naciskania na siłę (zwykle nie jest to dobry pomysł w środowisku zespołowym) jest:

1. git checkout feature / doing_stuff
2. git rebase rozwijać
3. git checkout rozwijać
4. git rebase feature / doing_stuff

Rebase z kroku 2 przenosi brakujące zatwierdzenie do feature / doing_stuff, więc gdy pojawia się krok 4, jest aktualny i nie ma potrzeby tworzenia nowego zatwierdzenia dla zmiany.

Jest to rozwiązanie, o którym wiem, że działa, ponieważ właśnie na to wpadłem i wykonałem powyższe kroki, aby pomyślnie uruchomić programowanie bez użycia siły. Pracuję w ponad 50-osobowym zespole programistów, więc nie wolno wymuszać niczego innego niż moje własne gałęzie testowe, więc musiałem znaleźć rozwiązanie.