Co dokładnie robi git rebase --skip?

107

Właśnie zrobiłem git pull --rebase origin masteri był konflikt.

Po pierwsze, ten konflikt był w pliku, którego nie dotknąłem i miał około 10 zatwierdzeń wstecz. Dlaczego to się dzieje?

Potem przypadkowo wpisałem git rebase --skip, a to „pominęło tę poprawkę”.

Martwiąc się, że pominąłem zatwierdzenie, sprawdziłem nową wersję gałęzi master i dokonałem różnicy między gałęzią, na której wykonałem rebase, a nową gałęzią master. Jedyne zmiany, które pojawiają się w różnicach, to ostatnie zatwierdzenie, a patrząc na dziennik, łatka, która została „pominięta”, pojawia się w historii zatwierdzeń.

Czy ktoś może wyjaśnić, co się tutaj dzieje?

git

— mrwooster
źródło

Jak przypadkowo piszesz git rebase --skip. Może źle? :)

— manojlds

Ha! Oznaczało napisanie - przerwane, ale z jakiegoś nieznanego powodu wyszło jako - pomiń. Tak naprawdę nie myślałem. :)

— mrwooster

historia powłoki jest w tym dobra (aby zmusić cię do wykonania czegoś, czego nie chciałeś).

— Florian Klein

Robi to, co mówi, pomija zatwierdzenie. Jeśli uruchomisz rebase --abortpóźniejszy konflikt podczas tej samej rebase, pominięte zatwierdzenie również zostanie oczywiście cofnięte.

Jeśli twoja zmiana istniała już wcześniej, Git nie będzie mógł zastosować twojego zatwierdzenia (ale zwykle powinien pominąć go automatycznie, jeśli łatka jest dokładnie taka sama). Twoje własne zatwierdzenie zostanie pominięte, ale zmiana będzie nadal istniała w bieżącym HEAD, ponieważ została już zastosowana w źródle.

Naprawdę powinieneś upewnić się, że nie usunąłeś swojej ważnej zmiany;) (użyj refloga, aby wrócić do stanu sprzed rebase)

— knittl
źródło

Dlaczego więc zatwierdzenie nadal pojawia się w dzienniku? I dlaczego brakujące zatwierdzenie pojawia się teraz w różnicy?

— mrwooster

Tak, konflikt został już rozwiązany na wcześniejszym etapie ... z jakiegoś powodu git rebase wyświetla stare konflikty scalania ... kolejna rzecz, która mnie dezorientuje? ... czy to oznacza, że pominął konflikt, ale zastosował poprawkę, która rozwiązała problem konflikt?

— mrwooster

Pominąłeś swoje własne zatwierdzenie, które miało taką samą zmianę jak zatwierdzenie powyżej. Pominąłeś swoje zatwierdzenie, ale zmiana została wprowadzona (ponieważ już istniała na początku strumienia)

— knittl

@mittal nie, nie sądzę, aby --skipto był właściwy sposób. Pomiń całkowicie pominie zatwierdzenie, usuwając wszystkie zmiany dokonane w tym zatwierdzeniu.

— knittl

@mittal: myśleć git rebasejak kopiowanie zobowiązuje z jednego oddziału na inny oddział. Więc kiedy pominiesz zatwierdzenie, oryginalna zawartość zatwierdzenia jest pomijana, a łatka nie jest stosowana (więc wszystkie zmiany wprowadzone w jakimkolwiek pliku nie trafią do gałęzi docelowej). Najłatwiejszym sposobem jest skonfigurowanie prostego repozytorium git z dwoma gałęziami, kilkoma zatwierdzeniami na każdym z nich, a następnie próba zmiany bazy i pominięcia zatwierdzenia (możesz użyć git rebase --interactivedo określenia, które zatwierdzenia zostaną skopiowane ( pick) lub pominięte ( skip)

— knittl