Git rebase - kontynuuj narzekanie nawet po rozwiązaniu wszystkich konfliktów podczas scalania


115

Mam problem, którego nie wiem, jak rozwiązać.

Zrobiłem rebase na mistrza z mojej filii:

git rebase master

i otrzymałem następujący błąd

 First, rewinding head to replay your work on top of it...
 Applying: checkstyled.
 Using index info to reconstruct a base tree...
 Falling back to patching base and 3-way merge...
 Auto-merging AssetsLoader.java
 CONFLICT (content): Merge conflict in AssetsLoader.java
 Failed to merge in the changes.
 Patch failed at 0001 checkstyled.

Poszedłem więc do mojego ulubionego edytora, naprawiłem konflikt 1 linii, zapisałem plik, wykonałem status git i otrzymałem następujące dane wyjściowe:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   PassengerContactHandler.java
 #
 # Unmerged paths:
 #   (use "git reset HEAD <file>..." to unstage)
 #   (use "git add/rm <file>..." as appropriate to mark resolution)
 #
 #  both modified:      AssetsLoader.java
 #

Zrobiłem git dodać AssetsLoader.java i status git i otrzymałem następujące informacje:

 # Not currently on any branch.
 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
 #
 #  modified:   AssetsLoader.java
 #  modified:   PassengerContactHandler.java
 #

a kiedy zrobiłem git rebase --continue, otrzymuję:

git rebase --continue
You must edit all merge conflicts and then
mark them as resolved using git add

Wiem, że mogę pominąć poprawkę i kontynuować rebase, ale nie jestem pewien, czy zmiany w PassengerContactHandler.java zostaną przeniesione do mojej gałęzi, czy nie.

więc nie jestem pewien, jak mam postępować?

Edycja: czy to możliwe, że plik z rozwiązanym konfliktem jest dokładnie taki sam, jak wersja oryginalna?

Wielkie dzięki, Lucas

Edytuj, znowu mi się to przydarzyło:

Po prostu znowu mi się to przydarzyło

(307ac0d...)|REBASE)$ git status
# Not currently on any branch.
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#   modified:   assets/world/level1/Level-1.xml
#   modified:   George.java
#   modified:   DefaultPassenger.java
#
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#   mb-art/originalAssets/27dec/

((307ac0d ...) | REBASE) $ git rebase --continue

You must edit all merge conflicts and then
mark them as resolved using git add

git - wersja

git version 1.7.1

To jest pełna wydajność git status, prawda? Brak brakującej sekcji poniżej?
Cascabel

git-rebasenigdy nie powinni zgłaszać, że istnieją nierozwiązane konflikty, jeśli takich nie ma. Jeśli uda Ci się odtworzyć problem w prostszym przypadku testowym, debugowanie byłoby znacznie łatwiejsze, ale nadal, jeśli nie git statuszgłaszasz żadnych konfliktów, kiedy tak się git rebase --continuedzieje, a Twoja wersja Git jest aktualna, możesz spróbować wysłać e-mail do programisty Git lista mailingowa pod adresem git@vger.kernel.org zawierająca jak najwięcej informacji diagnostycznych.
Cascabel

1
Po prostu znowu mi się to przydarzyło, (307ac0d ...) | REBASE) $ git status # Obecnie nie ma w żadnej gałęzi. # Zmiany do zatwierdzenia: # (użyj "git reset HEAD <file> ..." do unstage) # # zmodyfikowane: asset / world / level1 / Level-1.xml # modified: George.java # modified: DefaultPassenger.java # # Nieśledzone pliki: # (użyj „git add <file> ...”, aby uwzględnić to, co zostanie zatwierdzone) # # mb-art / originalAssets / 27dec /
Lucas

Myślę, że powinieneś użyć GITKRAKENA, pomoże ci w rozwiązaniu twoich konfliktów
Nikhil Bhardwaj

Odpowiedzi:


115

Dzieje się tak, ponieważ podczas naprawiania konfliktu usunąłeś cały kod z łatki zastosowany do gałęzi, na której się opiera. Użyj, git rebase --skipaby kontynuować.

Trochę więcej szczegółów:

Zwykle, naprawiając konflikt podczas ponownego bazowania, edytujesz plik będący w konflikcie, zachowując część lub całość kodu z łatki, która jest obecnie stosowana w gałęzi, na której bazujesz. Po naprawieniu poprawki i zrobieniu

git add your/conflicted/file
git status

otrzymasz (zwykle zieloną) linię pokazującą zmodyfikowany plik

zmodyfikowany: twój / konflikt / plik

git rebase --continue będzie działać dobrze w tej sytuacji.

Czasami jednak, rozwiązując konflikt, usuwasz wszystko z nowej łatki, zachowując tylko kod z gałęzi, na której się zmieniłeś. Teraz, kiedy dodasz plik, będzie on dokładnie taki sam, jak ten, na którym próbujesz zmienić bazę. Status git nie pokaże zielonej linii wyświetlającej zmodyfikowane pliki. Teraz, jeśli to zrobisz

git rebase --continue

git będzie narzekał

Bez zmian - zapomniałeś użyć „git add”?

To, czego naprawdę chce, żebyś zrobił w tej sytuacji, to użycie

git rebase --skip

aby pominąć poprawkę. Wcześniej nigdy tego nie robiłem, ponieważ zawsze nie byłem pewien, co właściwie zostałoby pominięte, gdybym to zrobił, nie było dla mnie oczywiste, co tak naprawdę oznacza „pomiń tę łatkę”. Ale jeśli nie uzyskasz zielonej linii z

zmodyfikowany: twój / konflikt / plik

po edycji pliku w konflikcie, dodaniu go i wykonaniu statusu git, możesz być prawie pewien, że usunąłeś całą poprawkę i możesz zamiast tego użyć

git rebase --skip

kontynuować.

Oryginalny post powiedział, że to czasami działa:

git add -A
git rebase --continue
# works magically?

... ale nie polegaj na tym (i pamiętaj, aby nie dodawać pozostałych plików do folderów repozytorium)


1
Wydawało mi się, że mam ten sam problem i to samo rozwiązanie, wydawało się też magiczne!
bspink

Miałem ten sam problem, wygląda na to, że gdybyś refaktoryzował się w nowej gałęzi i dodawał nowe pliki, a następnie proces rozwiązywania scalania wprowadził zmiany w tych nowych plikach, musisz jawnie dodać je ponownie.
Ibrahim

Nie rób tego, chyba że chcesz śledzić wszystkie niepotrzebne pliki w repozytorium.
Jed Lynch

git add ...staje się naprawdę irytujące po zmianie stosu plików z długimi ścieżkami. Czy git add --all-the-files-i-changedmogę biegać wcześniej git rebase continue?
jozxyqk

3
Aby zachować ostrożność podczas korzystania z polecenia git rebase --skip, możesz stracić swoją pracę (edytowane pliki)
Youness Marhrani


8

Otrzymałem to ostrzeżenie, gdy miałem niestabilne pliki. Upewnij się, że nie masz żadnych plików niestacjonarnych. Jeśli nie chcesz, aby pliki niestacjonarne uległy zmianie, odrzuć zmiany za pomocą

git rm <filename>  

2
Tak prosty, że mógłby to być komentarz; tak pomocna, że ​​powinna być odpowiedzią. Dzięki!
Lucas Lima

4

Spróbuj uruchomić to w linii poleceń:

$ git mergetool

Powinien wywołać interaktywny edytor umożliwiający rozwiązanie konfliktów. Łatwiejsze niż próba zrobienia tego ręcznie, a także git rozpozna, kiedy wykonasz scalanie. Pozwoli również uniknąć sytuacji, w których przypadkowo nie dokonasz pełnego scalenia, co może się zdarzyć, gdy spróbujesz to zrobić ręcznie.


Pomyślałem, że może to być łatwiejsze, a także pozwoli Ci uniknąć takich sytuacji w przyszłości.
Batkins

1
Uratowałeś mi wieczór. Chociaż jest to proste narzędzie, ale nigdy nie byłbym w stanie dowiedzieć się, jak rozwiązać moje konflikty bez tego narzędzia.
eonil

4

Po naprawieniu konfliktu upewnij się, że zmienione pliki zostały dodane do plików pomostowych. To rozwiązało problem.


To załatwiło sprawę dla mnie. Sprawdziłem Sourcetree po otrzymaniu wiadomości opisanej w OP i od razu zobaczyłem dwa pliki wymienione w oknie poleceń jako niestacjonarne. Przygotowałem pliki, uruchomiłem polecenie „git rebase --continue” i wróciłem na właściwe tory.
Mass Dot Net

3

Przegapiłeś konflikt scalania w AssetsLoader.java. Otwórz go i poszukaj znaczników konfliktu (">>>>", "====", "<<<<<"), a następnie ponownie dodaj git. Wykonaj „git diff --staged”, jeśli masz trudności ze znalezieniem go.


3
Wykonałem grep na wszystkich śledzonych plikach i nie było znaczników konfliktu.
Lucas

Czy git diff --stagedujawnia coś przydatnego? Wskazuje to, jakie zmiany zamierzasz wprowadzić, aby rozwiązać konflikt (y) scalania w tym momencie w rebase. W jednym z plików powinien znajdować się fragment „Ups, nie to zamierzałem zrobić, aby rozwiązać ten problem”.
Eter

4
Git nie szuka scalających znaczników konfliktów, gdy próbujesz przejść dalej. Po prostu sprawdza, czy indeks jest w stanie czystym. Jeśli przygotowałeś plik, który nadal zawiera znaczniki konfliktów, oznacza to, że chcesz go z nimi zatwierdzić. Prawdopodobnie zawsze jest to błąd, ale pozwoli ci to zrobić.
Cascabel

@Ether to wcale nie jest powód. Możesz git addplik nawet ze znacznikami konfliktu. W końcu takie pliki mogą być całkowicie legalne!
fge

@Jefromi: ha, dobrze wiedzieć! Zawsze zakładałem, że znaczniki są sprawdzane i trzeba by - sforsować to, jeśli było to zamierzone.
Eter

3

Właśnie miałem ten problem i chociaż myślę, że może być kilka przyczyn, oto moje ...

Miałem hak przed zatwierdzeniem gita, który odrzucał zatwierdzenia w pewnych warunkach. Jest to dobre w przypadku ręcznego zatwierdzania, ponieważ wyświetli wynik przechwytywania i mogę to naprawić lub zignorować za pomocą commit --no-verify.

Wydaje się, że problem polega na tym, że podczas zmiany bazy, rebase --continue również wywoła hook (w celu zatwierdzenia ostatniej serii zmian). Ale rebase nie wyświetli wyjścia przechwytywania, po prostu zobaczy, że się nie powiodło, a następnie wypluje mniej konkretny błąd mówiący `` Musisz edytować wszystkie konflikty scalania, a następnie oznaczyć je jako rozwiązane za pomocą git add ''

Aby to naprawić, przygotuj wszystkie swoje zmiany i zamiast robić „git rebase --continue”, wypróbuj „git commit”. Jeśli cierpisz na ten sam problem z hakiem, powinieneś zobaczyć powody, dla których nie działa.

Co ciekawe, podczas gdy git rebase nie wyświetla wyjścia z haka git, akceptuje opcję --no-verify, aby ominąć zaczepy.


1
Miałem podobny problem. Nic innego nie zadziałało dla mnie, ale po prostu wykonanie „git commit”, a następnie przerwanie wydawało się w magiczny sposób rozwiązać wszelkie rozbieżności, a wtedy udało mi się pomyślnie „git rebase --continue”.
patrickvacek

Tak dla porządku, ponieważ ostatnio borykałem się z podobnym problemem, git rebaseakceptuje --no-verifyopcję. Jednak pomija tylko przechwycenie pre-rebase, ale ta opcja nie jest stosowana przy kolejnych wywołaniach do git commit.
pkrysiak

Zawiera prawidłowy punkt (zmiany zatwierdzania), ale jest zbyt szczegółowy, aby dać dobrą odpowiedź.
Jack Miller

2

Po naprawieniu zmian możesz zapomnieć o uruchomieniu 'git add -A'

git add -A
git rebase --continue

1

Właśnie natknąłem się na ten problem. Nie zrobiłbym tego, git rebase --skip ponieważ git statuswyraźnie pokazałem przesunięcie modyfikacji, które chciałem zachować. Chociaż miałem kilka dodatkowych plików, które pojawiły się nieoczekiwanie. Rozwiązałem z

git checkout .

usunąć niestagowane modyfikacje, a potem się git rebase --continueudało.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.