2012-10-19 18 views
6

Posiadałem dwie gałęzie zarówno niezależne. Pracowałem nad nimi w różnych punktach przez miesiąc. Poszedłem połączyć jeden oddział (nazwijmy to apple) w drugim (nazwijmy to orange), sprawdzając pomarańczowe i robiąc git merge --no-ff apple i wszystko poszło dobrze. W gitku mogłem wyraźnie zobaczyć gałęzie, z których każda miała swoją własną historię i została scalona razem w scalonym zatwierdzeniu na pomarańczowo.git - rebase ruiny łączą się

Później zdaję sobie sprawę, że zatwierdzenie w kolorze pomarańczowym jest niepoprawne, wystąpił błąd w procesie kompilacji i muszę dokonać edycji tego wczesnego zatwierdzenia na pomarańczowo. Używam git rebase -i HEAD~19, wybierz commit i zmień pick na edit. Więc edytuję commit i wszystko jest w porządku, a ja kończę bazę. Wracam do gitk i cała historia tych dwóch gałęzi to jedna liniowa historia na pomarańczowo.

Więc coś spieprzyłem, czy to tak powinno być? Użyłem polecenia git reflog, aby wrócić do momentu, w którym zrobiłem scalenie, potem zrobiłem kolejny reset mocno, aby powrócić na prawo przed scaleniem na pomarańczowo, potem zrobiłem rebase i naprawiłem to zatwierdzenie, po czym zrobiłem scalenie. Teraz wszystko wygląda tak, jak bym się spodziewał, skoro przepowiednie z gałęzi nie są ze sobą splecione.

Czy w przyszłości może mi ktoś powiedzieć, w jaki sposób mogę dokonać reorganizacji commitów w oddziale, w którym połączyłem się w innym oddziale, bez kończenia z przeplotem (historia liniowa)?

Jeśli moja terminologia nie jest poprawna, możesz ją edytować. Jeszcze raz dziękuję

+0

Nie znam 'gitk' ale w' gitg' mam opcję wyboru oddziałów, czy wybrałeś coś takiego jak Wszystkie lokalne oddziały? –

+0

Być może należy dokonać ponownego wyboru dla identyfikatora zatwierdzenia zamiast względnego "HEAD ~ 19"? – nneonneo

+1

Zauważ, że git 1.8.5 wprowadzi [staranny sposób na zachowanie scalenia na 'pull --rebase'] (http://stackoverflow.com/a/18756102/6309) – VonC

Odpowiedz

9

Jest to oczekiwane zachowanie z bazy rebase. Skutecznie odświeża historię gałęzi, która powoduje (domyślnie) utratę scaleń i innych metadanych, pozostawiając prostą, uproszczoną gałąź.

Można zachować scala za pomocą

git rebase --preserve-merges 

ale są pewne problemy z łączenie --preserve-merges z --interactive. Unikaj uważnie.

+1

Interesujące, ale ma wadę: http://marc.info/?l=git&m=129382385207873 – VonC

+0

Tak właśnie miałem na myśli '-i'. '-i' ==' --interactive ". Myślę, że problem polega na tym, że czasami ponownie uporządkowana historia nie może właściwie zawierać historii scalania bez niszczenia danych. – willoller

+1

Wiem, co oznacza '-i', a moim celem było wspomnieć, że w połączeniu z' --preserve-merge', nie wydaje się rozwiązywać automatycznie znanych konfliktów. – VonC