Git odmawia połączenia niepowiązanych historii w bazie


2144

Podczas git rebase origin/developmentnastępującego komunikatu o błędzie jest wyświetlany z Git:

fatal: refusing to merge unrelated histories
Error redoing merge 1234deadbeef1234deadbeef

Moja wersja Git to 2.9.0. W poprzedniej wersji działało dobrze.

Jak mogę kontynuować ten rebase, umożliwiając niepowiązane historie z wymuszoną flagą wprowadzoną w nowej wersji?


12
@Shishya Z całym szacunkiem, najbardziej głosowana odpowiedź nie rozwiązuje tego pytania w bezpośredni sposób. Pytanie dotyczy git-rebasesytuacji, a odpowiedź daje flagęgit-merge
Shubham Chaudhary

13
@AsifMohammed to nie jest to, po co jest akceptowana odpowiedź . Ludzie automatycznie znajdą odpowiedź z największą liczbą głosów z powodu domyślnego sortowania według głosów.
Glorfindel,

2
W przypadku, gdy ktoś popełnił ten sam błąd, dostałem ten błąd po przypadkowym użyciu git pull [repo URL]zamiastgit clone [repo URL]
rsoren


35
Bałagan został wywołany przez fakt, że tytuł nie określa, że ​​jest to w kontekście bazy, więc twoje pytanie przyciąga Googlersów, którzy dostają ten błąd w różnych kontekstach i głosuje odpowiedź, która w rzeczywistości nie zastosuj się do zadanego pytania. Teraz nie można go łatwo usunąć, więc niespójna para pytań i odpowiedzi pozostanie w witrynie i na zawsze w wynikach wyszukiwania Google. Morał tej historii jest taki, że tytuły pytań mają znaczenie!
Mark Amery

Odpowiedzi:


2613

Domyślne zachowanie zmieniło się od Gita 2.9:

„git merge” pozwala na scalenie dwóch gałęzi, które domyślnie nie mają wspólnej bazy, co doprowadziło do powstania zupełnie nowej historii istniejącego projektu, a następnie wciągnięcia przez niczego niepodejrzewającego opiekuna, co pozwoliło na połączenie niepotrzebnej historii równoległej z istniejącym projektem . Polecenie zostało nauczone, aby domyślnie nie zezwalać na to , z --allow-unrelated-historiesopcją włazu awaryjnego, która może być używana w rzadkich przypadkach, które łączą historie dwóch projektów, które rozpoczęły swoje życie niezależnie.

Aby uzyskać więcej informacji, zobacz dziennik zmian wydania Git .

Możesz użyć, --allow-unrelated-historiesaby wymusić scalenie.


18
Poznaj zmianę scalania, ale ta opcja nie będzie działać z rebase
Shubham Chaudhary

3
Czy jest jakaś opcja, która włączy się na --allow-unrelated-historiesstałe?
jmarceli

4
@jmarceli „Ponieważ takie„ scalanie dwóch projektów ”jest rzadkim wydarzeniem, opcja konfiguracji umożliwiająca zawsze takie scalanie nie jest dodawana.” Więc nie.
blue112,

2
Próbowałem w ten sposób scalić gałąź dla innego repozytorium, ale utworzyłem nowy zatwierdzenie w moim obecnym oddziale i nie zachowałem historii od drugiego repozytorium. Potem sprawdziłem lokalny oddział z drugiego repozytorium i dopiero wtedy połączyłem go i nagle pojawiło się normalne zatwierdzenie scalania. Dziwne.
mgol

13
Doskonale, współpracuje git pullrównież. Był w tym „rzadkim wydarzeniu, które łączy historie dwóch projektów, które rozpoczęły swoje życie niezależnie”. git --work-tree="." pull --allow-unrelated-histories
Petru Zaharia,

1186

W moim przypadku błąd występował tylko fatal: refusing to merge unrelated historiesprzy każdej próbie, zwłaszcza przy pierwszym żądaniu ściągnięcia po zdalnym dodaniu repozytorium Git.

Użycie --allow-unrelated-historiesflagi działało w następujący sposób:

git pull origin branchname --allow-unrelated-histories

231
Zawsze widzę ten błąd, jeśli podczas tworzenia nowego repozytorium Github z plikiem README.md, po raz pierwszy ściągam go do lokalnego repozytorium. Tak denerwujące.
Tien Do

29
W przypadku nowych repozytoriów, pierwszych pociągnięć, zazwyczaj lepiej jest zacząć od git clone.
Parasol

3
adi

2
Zatrzymało mnie to na kilka godzin, zanim zdałem sobie sprawę, że musi istnieć oczywista rozdzielczość łączenia takich plików, jeśli ma to miejsce w przypadku plików domyślnych - Cieszę się, że nie jestem jedynym, który przynajmniej miał ten problem!
Zibbobz

3
W moim przypadku stało się tak, ponieważ dodałem plik licencji na github. Polecenie wspomniane powyżej (i poniżej są takie same) zadziałało.
uudaddy

579

Spróbuj wykonać następujące polecenie:

git pull origin master --allow-unrelated-histories

To powinno rozwiązać twój problem.


264

Wystąpił ten błąd, gdy najpierw skonfigurowałem lokalne repozytorium. Potem poszedłem do GitHub i utworzyłem nowe repozytorium. Potem pobiegłem

git remote add origin <repository url>

Kiedy próbowałem pchać lub ciągnąć, za fatal: unrelated_historieskażdym razem otrzymywałem ten sam błąd.

Oto jak to naprawiłem:

git pull origin master --allow-unrelated-histories
git merge origin origin/master
... add and commit here...
git push origin master

Myślę, że byliśmy na tej samej łodzi. Aby dodać coś: Mój problem polegał na tym, że już coś było na zdalnym repozytorium. Więc w moim folderze usunął .gitfolder, uruchomił git initi zrobił to, co powiedziała Adithya, z wyjątkiem części scalającej.
codepleb

1
Jak nacisnąć przycisk INSERT na komputerze Mac? Właściwie muszę wpisać komunikat zatwierdzenia i scalić z wiersza poleceń, ale nie wiem, jak to zrobić z wiersza poleceń.
Shajeel Afzal,

Czy to otwiera vim? Jeśli tak, to tylko SHIFT +:
Adithya Bhat

Nawet ja najpierw stworzyłem repozytorium GitHub i przechodziłem przez te polecenia dodawania repozytorium.
Pan Suryaa Jha,

1
To jest naprawdę dobra odpowiedź. Chodzi o to, że musisz wymusić pull, a następnie połączyć lokalne i zdalne repo.
alanwsx


135
git pull origin <branch> --allow-unrelated-histories

Nastąpi przekierowanie do okna edycji Vima:

  • Wstaw wiadomość zatwierdzenia
  • Następnie naciśnij Esc(aby wyjść z trybu „Wstaw”), następnie :(dwukropek), następnie x(małe „x”) i na koniec naciśnij, Enteraby wyjść z Vima
  • git push --set-upstream origin <branch>

5
Ctrl + X nie wyciągnie cię z Vima
Ruben

ale :x<Enter>będzie
webKnjaZ

101

Miałem ten sam problem. Spróbuj tego:

git pull origin master --allow-unrelated-histories 

git push origin master

47

Próbować git pull --rebase development


To rozwiązało mój problem. Oto jak zaczął się problem
Harlan Nelson

1
Powinno to być prawdopodobnie:git pull --rebase=preserve --allow-unrelated-histories development
Riccardo Murri

3
@RiccardoMurri Po wypróbowaniu tego nie zrobiłbym tego ponownie. Moje nowe repozytorium zawierało kilka przykładowych plików inicjujących, a moje lokalne repozytorium warte miesięcy. Uruchomienie tego ( newOrigin branchzamiast zamiast development) dodało początkowe zatwierdzenie na szczycie mojego lokalnego oddziału, skutecznie usuwając z niego prawie wszystko. Chciałem, aby początkowe zatwierdzenie z nowego pilota było na dole.
redOctober13

41

Dla Androida Studio i IntelliJ:

Najpierw popełnij wszystko i rozwiąż wszelkie konflikty.

Następnie otwórz terminal od dołu IDE i wprowadź:

git pull origin master --allow-unrelated-histories

Teraz możesz pchać.


38

OSTRZEŻENIE POTENCJALNIE NALEŻY PONOWNIE NAPRAWIĆ ZDALNE REPOZYTORIUM

To działało dla mnie:

git push origin master --force

1
Ale co tak naprawdę dzieje się z plikami lokalnymi i zdalnymi?
Prathamesh More

Jak wiem i doświadczenie, lokalne pliki są nienaruszone. Pliki zdalne, które chcesz dodać do określonego folderu, zostaną dodane.
Aniket Patil


Wystarczy dołączyć zastrzeżenie, że to polecenie zastępuje wszystkie pliki w gałęzi master . Działało dobrze dla mnie. Dzięki.
Flavio

1
Działa, ale jest dość trudny, a historia --allow-nonrelad jest bardziej szczegółowa i odpowiednia
bdulac

32

Ponieważ wszystkie pozostałe odpowiedzi w rzeczywistości nie odpowiadają na pytanie, oto rozwiązanie inspirowane tą odpowiedzią na powiązane pytanie.

Błąd pojawia się wtedy, gdy git rebase:

$ git rebase origin/development
fatal: refusing to merge unrelated histories
Error redoing merge 1234deadbeef1234deadbeef

Ten błąd nie anuluje rebase, ale jesteś teraz w jego trakcie:

$ git status
interactive rebase in progress; onto 4321beefdead
Last command done (1 command done):
   pick 1234deadbeef1234deadbeef test merge commit

Możesz teraz wykonać scalenie ręcznie. Dowiedz się, jakie są zatwierdzenia pierwotnego zatwierdzenia scalania:

$ git log -1 1234deadbeef1234deadbeef
commit 1234deadbeef1234deadbeef
Merge: 111111111 222222222
Author: Hans Dampf
Date:   Wed Jun 6 18:04:35 2018 +0200

    test merge commit

Sprawdź, który z dwóch rodziców scalających jest tym, który został scalony z bieżącym (prawdopodobnie drugim, sprawdź za pomocą git log 222222222), a następnie wykonaj scalenie ręcznie, kopiując komunikat zatwierdzenia oryginalnego zatwierdzenia scalania:

$ git merge --allow-unrelated 222222222 --no-commit
Automatic merge went well; stopped before committing as requested
$ git commit -C 1234deadbeef1234deadbeef
[detached HEAD 909af09ec] test merge commit
 Date: Wed Jun 6 18:04:35 2018 +0200
$ git rebase --continue
Successfully rebased and updated refs/heads/test-branch.

28

Miałem ten sam problem. Problem jest zdalny miał coś, co temu zapobiega.

Najpierw utworzyłem lokalne repozytorium. Dodałem plik LICENSEi README.mddo mojego pliku lokalnego i zatwierdziłem.

Potem chciałem zdalnego repozytorium, więc utworzyłem je na GitHub. Tutaj popełniłem błąd, sprawdzając „Zainicjuj to repozytorium za pomocą README” , co również zdalnie utworzyło README.md.

Więc teraz, kiedy uciekłem

git push --set-upstream origin master

Mam:

error: failed to push some refs to 'https://github.com/lokeshub/myTODs.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes
(e.g. hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Teraz to zrobiłem

git pull origin master

Co spowodowało następujący błąd:

From https://github.com/lokeshub/myTODs
branch            master     -> FETCH_HEAD
fatal: refusing to merge unrelated histories**

Próbowałem:

git pull origin master --allow-unrelated-histories

Wynik:

From https://github.com/lokeshub/myTODs
 * branch            master     -> FETCH_HEAD
Auto-merging README.md
CONFLICT (add/add): Merge conflict in README.md
Automatic merge failed;
fix conflicts and then commit the result.

Rozwiązanie:

Usunąłem zdalne repozytorium i utworzyłem nowy (myślę, że tylko usunięcie pliku READMEmogło zadziałać), a potem działały następujące czynności:

git remote rm origin
git remote add origin https://github.com/lokeshub/myTODOs.git
git push --set-upstream origin master

25
utworzenie nowego repozytorium nie jest rozwiązaniem
Zach

3
git pull master origin --allow-non-spokrewnione-historie pracowały dla mnie .. Dzięki
SKalariya

git push --force ... byłoby właściwym rozwiązaniem w kroku 1 w tym konkretnym przypadku
Konstantin Pelepelin

2
To nie jest rozwiązanie. Jeśli jesteś początkujący, możesz to zrobić, ale jeśli pracujesz z prawdziwymi projektami, powinieneś postępować we właściwy sposób.
Prathamesh More

27

Zwykle dzieje się tak, gdy pierwszy raz przypisujesz się do zdalnego repozytorium. Ponieważ błąd wyraźnie mówi „odmowa połączenia niepowiązanych historii”, musimy użyć flagi --allow-niezwiązane historie.

git pull origin master  --allow-unrelated-histories

Teraz będą pewne konflikty, które musimy rozwiązać ręcznie. Następnie wystarczy zatwierdzić kod i wcisnąć go.


Jak wspomniano w pytaniu, próbuję zrobić git-rebase, a nie git-pull, git-rebase nie ma --allow-unrelated-historiesflagi.
Shubham Chaudhary

24

Dwie możliwości, kiedy może się to zdarzyć -

  1. Sklonowałeś projekt i jakoś katalog .git został usunięty lub uszkodzony. To powoduje, że Git nie zdaje sobie sprawy z twojej lokalnej historii i dlatego powoduje zgłoszenie tego błędu podczas próby wypychania lub wyciągania ze zdalnego repozytorium.

  2. Utworzyłeś nowe repozytorium, dodałeś do niego kilka zatwierdzeń, a teraz próbujesz wyciągnąć ze zdalnego repozytorium, które już ma własne zatwierdzenia. W tym przypadku Git zgłosi błąd, ponieważ nie ma pojęcia, jak te dwa projekty są ze sobą powiązane.

ROZWIĄZANIE

git pull master master --allow-nonrelated-histories

Ref - https://www.educative.io/edpresso/the-fatal-refusing-to-merge-unrelated-histories-git-error


12

Walczyłem również z tym, ale udało mi się znaleźć obejście.

Gdy napotkasz powyższy błąd, po prostu wybierz Cherry zatwierdzenia scalania, a następnie kontynuuj rebase:

git cherry-pick -m 1 1234deadbeef1234deadbeef
git rebase --continue

3
Proszę w angielskim samolocie?
Agentka Zebra,

@AgentZebra Dla dowolnego dysku w płaszczyźnie złożonej całka ciągłej ścieżki zamkniętej wynosi 0.
Addem

12

Najpierw pociągnij zmiany lokalne do lokalnego za pomocą następującego polecenia:

git pull origin branchname --allow-unrelated-histories

** nazwa gałęzi jest w moim przypadku master.

Po wykonaniu polecenia pull występuje konflikt. Powinieneś rozwiązać konflikty. Używam Android Studio do rozwiązywania konfliktów. wprowadź opis zdjęcia tutaj

Po rozwiązaniu konfliktów scalanie jest zakończone!

Teraz możesz bezpiecznie pchać.


Szukałem przycisku do Resolve Conflictw AS. Czasami wyskakujące okienko / dymek z prawej strony znikają i nie jestem w stanie nic zrobić. Dzięki @oiyio
mochadwi


6

Kiedy robiłem a git pull, dostałem ten komunikat fatal: refusing to merge unrelated histories do modułu repo, w którym przez jakiś czas nie aktualizowałem lokalnej kopii.

Uruchomiłem to polecenie, aby odświeżyć lokalnie z miejsca pochodzenia. Chciałem tylko najnowsze zdalnie i nie potrzebowałem żadnych lokalnych zmian.

git reset --hard origin/master

To naprawiło to w moim przypadku.


12
OSTRZEŻENIE: Usunęło WSZYSTKIE moje pliki. Bądź ostrożny, jeśli nie wiesz, co robisz!
Salvi Pascual

2
Spowoduje to usunięcie wszystkich oczekujących zmian!
Orestis P.

1

Korzystam z bazy od lat i nigdy nie spotkałem się z takim problemem. Pierwszym problemem jest jednak próba zrobienia tego bezpośrednio w zdalnej gałęzi developmentze zdalnego repozytorium o nazwie origin. Jest to dosłownie złe, ponieważ rebase to niebezpieczne polecenie, które restrukturyzuje historię git. Powiedziawszy to, powinieneś najpierw wypróbować swoje lokalne repozytorium i wypchnąć je tylko, jeśli działa dla ciebie zgodnie z oczekiwaniami.

Tak więc mój zwykły proces rebase wygląda następująco (pamiętaj jednak, że nie powinieneś używać rebase dla oddziałów, których nie jesteś jedyną komisją. W przypadku takich oddziałów po prostu łącz i rozwiąż konflikty, jeśli dotyczy):

  1. upewnij się, że masz czyste drzewo robocze (bez niezamierzonych zmian)
  2. kasa do gałęzi, na której chcesz dokonać zmiany bazy (na przykład, powiedzmy, że to master; jako polecenie jednowierszowe):git checkout master && git pull origin master && git checkout development
  3. Wykonaj rzeczywistą zmianę bazy: git rebase master
  4. Jeśli jest zrobione i wszystko działa zgodnie z oczekiwaniami, popchnij go do pilota. Aby to zrobić, musisz to wymusić, ponieważ zdalny host ma już historię w innej kolejności, zdalny nie odpowiedziałby bez naciskania. Musimy więc powiedzieć „moja lokalna wersja historii jest poprawna, nadpisz wszystko w tym zdalnym oddziale, używając mojej lokalnej wersji historii”:git push -f origin development

Jak już wspomniałem, pamiętaj, że rebase manipuluje historią gitów, co zwykle jest złe. Można to jednak zrobić na oddziałach, do których nikt inny się nie zobowiązuje. Aby utrzymać ciągłość gałęzi dla innych programistów, użyj innej strategii scalania, takiej jak scalanie, squash lub cherrypick. Innymi słowy: Rebase nie powinno być narzędziem rozproszonego programowania. Działa dobrze, jeśli jesteś jedynym, który działa w tym repozytorium.

Używamy strategii gałęzi funkcji. W tym celu zwykle używam rebase, aby uzyskać „aktualizacje” od innych programistów, które w międzyczasie wydarzyły się w gałęzi master. Dzięki temu zmniejsza rozmiar zatwierdzeń widocznych w żądaniu ściągnięcia. Dlatego recenzentowi kodu łatwiej jest zobaczyć moje zmiany dokonane w tej gałęzi funkcji.


W tym przypadku naprawdę chciałem kontynuować rebase i odpowiedź na to pytanie nie rozwiązuje problemu. Wiem, jakie jest ryzyko ponownego bazowania i kiedy powinienem i nie powinienem używać git-rebase. Jest to ogólna (opiniotwórcza) wytyczna dla przepływu pracy git i nie odpowiada bezpośrednio na pytanie. Jeśli chodzi o używanie bazy danych przez lata, ten konkretny błąd został dodany w wersji 2.9.0 programu git, a przepływ działał dobrze przed tym wydaniem. Odpowiedź na to, co napisałeś tutaj w tej odpowiedzi, jest już dostępna w wielu starszych pytaniach, takich jak stackoverflow.com/a/11566503/2670370 i git-scm.com/book/en/v2/Git-Branching-Rebasing
Shubham Chaudhary

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.