Ponowne wykonanie przywróconego scalania w Git

Question

Mam tu do czynienia z pewnym problemem: miałem gałąź specyficzną dla problemu 28s w Git, którą połączyłem w ogólnym oddziale develop. Okazuje się, że zrobiłem to zbyt szybko, więc użyłem git-revert, aby cofnąć scalenie. Teraz jednak nadszedł czas, aby połączyć 28s w develop, ale polecenie git-merge widzi oryginalne scalenie i radośnie informuje, że wszystko jest dobrze, a gałęzie zostały już scalone. Co mam teraz zrobić? Utwórz "Przywróć" Przywróć "28s ->" "commit"? Nie wydaje się to dobrym sposobem na zrobienie tego, ale nie mogę sobie teraz wyobrazić żadnego innego.

Co struktura drzewa wygląda następująco:

Answer 1

Trzeba "przywrócić Przywróć". Zależy, w jaki sposób to powróciłeś, może nie być tak proste, jak się wydaje. Spójrz na official document on this topic.

---o---o---o---M---x---x---W---x---Y 
      /
     ---A---B-------------------C---D 

aby umożliwić:

---o---o---o---M---x---x-------x-------* 
      /     /
     ---A---B-------------------C---D 

Ale to wszystko działa? Pewnie, że tak. Możesz odwrócić scalanie i pod kątem czysto technicznym, git zrobił to bardzo naturalnie i nie miał prawdziwych problemów z .
Po prostu uznało to za zmianę ze stanu "przed scaleniem" na "stan po scaleniu", i to było to.
Nic skomplikowanego, nic dziwnego, nic naprawdę niebezpiecznego. Git zrobi to bez myślenia o tym.

więc z technicznego punktu widzenia, nie ma nic złego w powracanie do seryjnej, ale od kąta workflow to coś, czego na ogół powinien starać się unikać .

Jeśli to możliwe, na przykład, jeśli pojawi się jakiś problem, który został połączyła do głównego drzewa, zamiast przywrócić seryjnej, spróbuj naprawdę trudno:

• przepoławiać problem w dół do połączonej gałęzi i po prostu ją napraw,
• lub spróbuj powrócić do pojedynczego zatwierdzenia, które spowodowało.

Tak, jest to bardziej skomplikowane, a nie, to nie zawsze będzie działać (czasem odpowiedź brzmi: „Oj, ja naprawdę nie powinno połączyły go, ponieważ nie było jeszcze gotowe, a Naprawdę muszę cofnąć wszystkie scalenia "). Tak więc naprawdę powinieneś przywrócić scalanie, ale kiedy chcesz ponownie wykonać scalenie, musisz wykonać to przez odwrócenie cofnięcia.

Answer 2

Zamiast git-revert mogłeś stosować tego polecenia w devel oddział do wyrzucić (aś) źle scalającej (zamiast tylko powracanie go).

git checkout devel 
git reset --hard COMMIT_BEFORE_WRONG_MERGE 

Spowoduje to również odpowiednie dostosowanie zawartości katalogu roboczego. Uważać:

• Zapisz zmiany w branży rozwoju (od niewłaściwej scaleniu), ponieważ też zostaną usunięte przez git-reset. Wszystkie zatwierdzenia po tym, który określisz jako argument , znikną!
• Nie rób tego również, jeśli zmiany zostały już pobrane z innych repozytoriów , ponieważ reset spowoduje przepisanie historii.

Zaleca się dokładne przestudiowanie strony manprzed wykonaniem tej czynności.

Teraz, po resecie można ponownie zastosować zmiany w devel a następnie zrobić

git checkout devel 
git merge 28s 

Będzie to prawdziwe scalenie z 28s do devel jak początkowego (który jest teraz wymazane z git na historia).

Answer 3

Załóżmy masz taką historię

---o---o---o---M---W---x-------x-------* 
      /      
     ---A---B 

Gdzie A, B powiodło commity i W - jest powracają M

Więc zanim zacznę utrwalanie znalazł problemy Mam cherry-pick W zobowiązać się do mój oddział

git cherry-pick -x W 

Potem powróci W popełnić na moim oddziale

git revert W 

Po tym, jak mogę kontynuować poprawianie.

Ostateczna historia mogłaby wyglądać następująco:

---o---o---o---M---W---x-------x-------* 
      /     / 
     ---A---B---W---W`----------C---D 

Kiedy wysłać PR będzie to jasno pokazuje, że PR jest cofnąć Cofnij i dodaje nowe rewizje.

Answer 4

Aby przywrócić Przywróć bez zakręcania przepływ pracy zbyt wiele:

• utworzyć lokalną kopię dziadostwa rozwijać
• przywrócić powracają popełnić na lokalnej kopii rozwijać
• seryjnej że skopiowania do swojej gałąź funkcji i popchnij gałąź z funkcjami do serwera git.

Twój oddział funkcji powinien teraz zostać scalony jak zwykle, kiedy będziesz na to gotowy. Jedynym minusem jest to, że będziesz mieć kilka dodatkowych scaleń/rewersów w twojej historii.

Answer 5

Właśnie znalazłem ten post w obliczu tego samego problemu. Uważam, że powyżej jest to dość przerażające, aby zresetować hards itd. Kończę usuwanie czegoś, czego nie chcę, i nie będę mógł go odzyskać.

Zamiast tego sprawdziłem zatwierdzenie, które chciałem, aby gałąź wróciła do np. git checkout 123466t7632723. Następnie przekonwertowano na gałąź git checkout my-new-branch. Następnie usunąłem gałąź, której nie chciałem więcej. Oczywiście zadziała to tylko wtedy, gdy będziesz w stanie wyrzucić uszkodzoną gałąź.