2011-06-27 12 views
10

Zrobiłem git pull z mojego upstream na czysty katalog roboczy i przedstawia mi konflikty scalania. Spędziłem około godziny ręcznie, resetując je, myśląc, że coś spieprzyłem i to się powtórzyło.git pull z katalogu czystego ma konflikty scalania

Czy to błąd w git? Niewiele o tym wiem, więc w pełni zgadzam się na to, że zrobiłem to dla siebie.

Oto moje wyjście obcięta (zdarza się około 9 plików, ale chciałem, aby zaoszczędzić miejsce, a nazwy plików zostały zmienione w celu ochrony niewinnych):

$ git status 
# On branch master 
nothing to commit (working directory clean) 
$ git pull 
Auto-merged xxxx/xxxx/xxxx.xxx 
CONFLICT (content): Merge conflict in xxxx/xxxx/xxxx.xxx 
Automatic merge failed; fix conflicts and then commit the result. 

używam Solaris 11 Express, z domyślny pakiet git.

$ uname -a 
SunOS xxxx 5.11 snv_151a i86pc i386 i86pc Solaris 
$ git --version 
git version 1.5.6.5 
$ pkg list git 
NAME (PUBLISHER)        VERSION   STATE  UFOXI 
developer/versioning/git      1.5.6.5-0.151.0.1 installed ----- 

Znalazłem to pytanie: Git pull fails: You have unstaged changes. Git status: nothing to commit (working directory clean), co wydaje się najbliżej ale ma odpowiedź niezadowalające.

Jak mogę to zrobić bez usuwania całego mojego repozytorium i tworzenia nowego klonu?

Odpowiedz

15

Twój katalog roboczy może być czysty, ale masz jedno lub więcej zatwierdzeń, które wykonałeś lokalnie, a które nie są na serwerze. Kiedy ciągniesz, git próbuje scalić te lokalne zatwierdzenia z tymi na serwerze, ale ponieważ modyfikują ten sam obszar kodu, są w konflikcie.

Twoje opcje tutaj w zasadzie sprowadzają się do:

  1. Fix the conflicts. powiedzieć git, jak radzić sobie sprzeczne zmiany i przejść dalej.
  2. Rozwiń i usuń konflikty za pomocą git pull --rebase. Nie różni się to znacznie od 1, ale jeśli twoje zmiany nigdy nie zostały opublikowane (tj. Nigdy nie zostały wypchnięte, nigdy), może ci to zapewnić czystszą (liniową) historię.
  3. Odrzuć lokalne zmiany i użyj pilotów, z git reset --hard remotename/remotebranch. Spowoduje to utratę wszelkich zmian, które popełniłeś na miejscu, ale które nie zostały zepchnięte gdzie indziej.
+1

Nie mam żadnych lokalnych zatwierdzeń w tym oddziale, ale # 3 wykonał lewę, dzięki. – bahamat

+4

Przydatna odpowiedź, pomogła mi znaleźć wyjście z chwastów. W moim przypadku uruchomiłem "git rebase master" w oddziale. Potem miałem konflikt scalania, jak opisano powyżej. Rozwiązany z "git merge --abort", a następnie "git pull --rebase". Dzięki! – wndxlori

0

Wyciąganie, rozwiązywanie konfliktów scalania i zatwierdzanie? Nawet jeśli dysponujesz czystym katalogiem roboczym, jeśli popełniłeś pewną pracę, która koliduje z nadchodzącymi zmianami, pojawia się konflikt scalania.

0

Dodawanie do bdonlan odpowiedź, może się zdarzyć, gdy masz jakieś rewizje (na lokalnym repozytorium), ale zdalne repozytorium wyprzedza (miał pewien postęp w stosunku do lokalnych plików zaangażowanych).

Po prostu utknąłem, gdy nie mogłem naciskać ani ciągnąć z powodu tych konfliktów.

próbował zrobić 'rebase' lub 'zresetowane --hard' bez powodzenia.

Jedynym rozwiązaniem, które zadziałało, było cofnięcie jednego zatwierdzenia i wycofanie;

Wykonaj następujące kroki:

Ostrzeżenie: jest to destrukcyjne działanie, które spowoduje, że ci utraty ostatnich zmian do tego kodu, tak zapasowych zmian pierwszy!

  1. Użyj „log git” na lokalnym repozytorium i porównać to do zobowiązuje się zalogować na pilocie - aby zrozumieć, które z twoich zatwierdzeń nie został wciśnięty
  2. Użyj 'git zresetować --hard „aby powrócić do ostatniego czasu kod pasuje do zdalnego repozytorium (użyłem” git zresetować --hard HEAD^ „celowo stracić mojego poprzedniego commit)
  3. teraz” git ciągnąć "będzie działać; użyj go, aby uzyskać najnowszy kod ze zdalnego serwera