2014-11-12 16 views
10

Postanowiłem wrócić kilka razy, ponieważ ścieżka, którą podążałem była błędna. Sprawdziłem więc zatwierdzenie Added cordova to .gitignore i wprowadziłem pewne modyfikacje. Jak pokazano poniżej:Git - Ustaw lokalny HEAD na nowego mistrza

enter image description here

Teraz kiedy wciskam nowe modyfikacje, komunikat o błędzie pojawia się:
error: src refspec (detached from aad6423) does not match any.

Jak mogę powiedzieć git odrzucić wcześniejsze rewizje (w kolorze fioletowym) i kontynuować z moim lokalnym HEADem jako mistrzem?

+1

Jeśli pracujesz z innymi osobami, prawidłowym sposobem postępowania z tym będzie prawdopodobnie przywrócenie twoich zmian na górze 'master'. zobacz http://stackoverflow.com/a/1470452/671543 – njzk2

+0

możliwy duplikat [Git: przenieś wskaźnik gałęzi do innego zatwierdzenia] (http://stackoverflow.com/questions/5471174/git-move-branch-pointer-to -different-commit) –

+0

Kolejne proste zadanie utrudnione przez Gita. Deweloperzy Git powinni używać Stack Overflow jako informacji zwrotnej w ich pętli SDLC. Muszą zatrudnić eksperta UX, ponieważ wyraźnie nie mogą tego zrobić samodzielnie. – jww

Odpowiedz

10

Nawet jeśli nie chcesz już tej starej gałęzi, git naprawdę nie lubi przepisywania historii lub odrzucania zmian. Po prostu odwróć i scal.

git branch new_master    # name current detached HEAD 
git checkout master    # switch back to master 
git revert --no-edit HEAD~4..HEAD # create commits reverting back to where the history split 
git merge new_master    # merge 
git branch -d new_master   # don't need it anymore 
git branch new_master    # name current detached HEAD 
git checkout master    # switch back to master 
git revert --no-edit HEAD~4..HEAD # create commits reverting back to where the history split 
git merge new_master    # merge 
git branch -d new_master   # don't need it anymore 
+0

Myślę, że to jest poprawna odpowiedź, chociaż jej nie próbowałem. Zasadniczo, jeśli już zostałeś przeniesiony do zdalnego repozytorium, możesz zastąpić zmiany za pomocą 'git push -f', ale to jest trochę antyspołeczne, zwłaszcza jeśli inni deweloperzy już zsynchronizowali twoje zmiany. W tym momencie musisz zastosować odwrotną poprawkę do 'master', która przywróci ją do stanu sprzed fork, a następnie zastosować do niej nowy commit' HEAD', a następnie pchnąć. –

+1

możesz zmienić temat "tematu", jeśli nie lubisz diamentów (lub nawet czereśnia - wybierz, jak widać, jest tylko 1 commit) – njzk2

+0

Kolejne proste zadanie utrudnione przez Gita. Deweloperzy Git powinni używać Stack Overflow jako informacji zwrotnej w ich pętli SDLC. Muszą zatrudnić eksperta UX, ponieważ wyraźnie nie mogą tego zrobić samodzielnie. – jww

1

Ponieważ masz rozbieżność, musisz zniszczyć pilota zdalnego i wypchnąć wersję lokalną. W zależności od bezpieczeństwa w miejscu, możesz nie być w stanie tego zrobić. Ma to również inne implikacje, w zależności od tego, kto wykonuje pracę opartą na kapitanie. Należy to zrobić z zachowaniem szczególnej ostrożności.

git push origin :master // deletes remote master 
git push origin master // pushes local master to remote 

Innym (prawdopodobnie lepszym) rozwiązaniem byłoby przywrócenie zatwierdzeń do zatwierdzenia i zatwierdzenie przywracania (które same są zatwierdzane). Potem wybierz, jaką pracę wykonałeś na swoim lokalnym. Najpierw utwórz lokalnie nową gałąź tematyczną, aby zapisać swoją pracę.

git checkout -b <topic_branch_name> // create new branch to save local work 
git checkout master 
git reset --hard HEAD // sync local master to remote HEAD 

git revert <last commit to master> 
git revert <second-to-last commit to master> 
... 
git revert <Added cordova to .gitignore commit> 
git push 

git cherry-pick <commit hash from topic branch commit(s)> 
+0

Najpierw musisz załączyć 'HEAD' ... – Max

+0

Nie jestem pewien czy podążam. Może moja edycja pomaga wyjaśnić. – isherwood

+0

Twoja poprawka naprawiła go za pomocą 'checkout -b'. – Max

0

Odkąd popchnąłeś zmiany w górę, lepszym rozwiązaniem jest przywrócenie ich za pomocą innego zatwierdzenia. Zatwierdzenie, które cofnie zmiany. Usuwanie zatwierdzeń lub gałęzi z wyższego poziomu odbywa się pod złą praktyką. Więcej informacji można znaleźć w tej wersji: answer.

+0

@EdwardFalk Tylko przekazanie do nowego zatwierdzenia nie powiodło się. Ale jeśli oddział zostanie zmieniony (usuń zatwierdzone już poprawki), spowoduje to konflikt dla wszystkich innych deweloperów. – dan

12

Producent HEAD swój nowy lokalny master:

$ git checkout -B master 

Siła-Push zmiany:

$ git push -f 
+0

Może to być niebezpieczne, jeśli pracujesz z innymi. Bądź świadom tego, że forsowanie przemocy przerobi historię, powodując, że inni będą musieli poradzić sobie z nową historią. –

+2

@BrianJ Zgoda, odpowiedź Maxa brzmi: co powinieneś zrobić w 99% przypadków. Ale tak właśnie robisz dokładnie to, o co prosił OP. –

+0

To dla mnie jak magia. :) Używam Sourcetree btw. Niebezpieczny dla innych, ale miałem taki sam przypadek z OP. Potrzebowałem mojego HEAD, aby być mistrzem. Dzięki! – Glenn

0

Tak, chciałbym to zrobić na kilka etapów:

git co -b new_master 

do zdobądź miłe referencje do tego, co chcesz nowego mistrza.

git co master ; git co -b old_master 

zachować referencję dla starego mistrza na wypadek, gdybyś chciał wrócić lub coś później; zawsze możesz usunąć tę gałąź później, gdy jesteś tego pewien.

git co master ; git reset --hard new_master 

spowoduje to zresetowanie HEAD oddziału, w którym się znajdujesz (master) do podanego odwołania (new_master).

git push -f origin 

to zrobi nacisk na siłę twojej nowej głównej gałęzi do pilota. Zauważ, że jest to zła praktyka, jeśli ktoś używa twojego zdalnego repo, ponieważ może to potencjalnie przerwać ich pobrania/wyciągnięcia.

Powiązane problemy