Porównaj ceny domen i usług IT, sprzedawców z całego świata
git

Jak można pogodzić wolnostojącą HEAD z mistrzem/pochodzeniem?


Jestem nowy w skomplikowanych gałęziach Git. Zawsze pracuję na tej samej gałęzi i zatwierdzam zmiany, a następnie okresowo wysyłam do mojego zdalnego źródła.
Niedawno zrobiłem zrzut niektórych plików, aby usunąć je z etapu commit (commit), a później wykonałem
rebase -i
, aby pozbyć się kilku ostatnich lokalnych zatwierdzeń. Teraz jestem w stanie, którego nie do końca rozumiem.
W moim obszarze roboczym
git log
pokazuje dokładnie to, czego bym się spodziewał - jestem we właściwym pociągu z zatwierdzeniami, których nie chciałem opuszczać, nowymi, itp.
Ale właśnie poszedłem do zdalnego repozytorium i tam wszystko jest inne - kilka zatwierdzeń, które zabiłem w rebase, zostało przeniesionych, ale nowych, zatwierdzonych lokalnie, nie ma.
Myślę, że „master/origin” jest niezależny od HEAD, ale nie bardzo rozumiem, co to znaczy, jak wyrenderować go za pomocą narzędzi wiersza poleceń i jak to naprawić.
Zaproszony:
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Po pierwsze, wyjaśnijmy
co to jest HEAD
https://git-scm.com/book/en/v2 ... ences

i co to znaczy, kiedy jest odłączony.
HEAD to symboliczna nazwa aktualnie pobranego zatwierdzenia. Kiedy GŁOWA nie jest odłączona („normalna” sytuacja
<sup>
1
</sup>: masz wyrejestrowaną gałąź), HEAD faktycznie wskazuje na gałąź „ref”, a gałąź wskazuje na zatwierdzenie (zatwierdzenie). Zatem HEAD jest „dołączony” do gałęzi. Kiedy robisz nowe zatwierdzenie (zatwierdzenie), gałąź, na którą wskazuje HEAD, jest aktualizowana, aby wskazywać na nowe zatwierdzenie (zatwierdzenie). HEAD podąża automatycznie za wskazaniem gałęzi.
  • git symbolic-ref HEAD
    zwraca
    refs/heads/master
    Gałąź o nazwie „master” jest wyrejestrowana.
  • Yield
    git rev-parse refs/heads/master
    17a02998078923f2d62811326d130de991d1a95a
    To zatwierdzenie jest aktualną wskazówką lub „nagłówkiem” głównej gałęzi.
  • git rev-parse HEAD
    daje również
    17a02998078923f2d62811326d130de991d1a95a
    Oto, co to znaczy być „symbolicznym odniesieniem”. Wskazuje na obiekt za pośrednictwem innego łącza. (Dowiązania symboliczne były pierwotnie implementowane jako dowiązania symboliczne, ale później zostały zmienione na proste pliki z dodatkowymi interpretacjami, dzięki czemu można ich używać na platformach bez dowiązań symbolicznych).

Mamy
HEAD
refs/heads/master
17a02998078923f2d62811326d130de991d1a95a
Kiedy HEAD odłącza się, wskazuje bezpośrednio na zatwierdzenie - zamiast pośrednio wskazywać go przez gałąź. Możesz myśleć o osobnej HEAD jako o nienazwanej gałęzi.
  • git symbolic-ref HEAD
    kończy się niepowodzeniem z
    fatal: ref HEAD nie jest symbolicznym odnośnikiem
  • git rev-parse HEAD
    daje
    17a02998078923f2d62811326d130de991d1a95a
    Ponieważ nie jest to dowiązanie symboliczne, musi wskazywać bezpośrednio na samo zatwierdzenie.

Jesteśmy
HEAD
17a02998078923f2d62811326d130de991d1a95a
Ważne jest, aby pamiętać, że po odłączeniu HEAD, zatwierdzenie, na które wskazuje, nie jest w inny sposób odwołane (żaden inny ref nie może go dosięgnąć), stanie się „wiszące”, gdy sprawdzisz inny commit. Ostatecznie takie wiszące zatwierdzenia zostaną obcięte podczas procesu czyszczenia pamięci (domyślnie są przechowywane przez co najmniej 2 tygodnie i mogą trwać dłużej, jeśli odwołuje się do nich reflog HEAD).
<sup>
1
</sup>
całkowicie w porządku jest wykonywać „normalną” pracę z odłączoną głowicą HEAD, wystarczy śledzić, co robisz, aby uniknąć konieczności pobierania porzuconej historii z reflogu.
Pośrednie kroki interaktywnego podbicia są wykonywane z odłączoną HEAD (częściowo w celu uniknięcia zanieczyszczenia reflogu aktywnej gałęzi). Jeśli zakończysz pełną operację rebase, zaktualizuje ona oryginalną gałąź o skumulowany wynik operacji ponownej bazy i ponownie dołączy HEAD do oryginalnej gałęzi. Zakładam, że nigdy nie ukończyłeś całkowicie procesu rebase; pozostawi ci to odłączony HEAD wskazujący na zmianę, która została ostatnio zmieniona.
Aby wyjść z tej sytuacji, musisz stworzyć gałąź, która wskazuje na zmianę, na którą wskazuje twój odłączony HEAD:
git branch temp
git checkout temp

<sub>
(te dwa polecenia można skrócić jako
git checkout -b temp
</sub>
)
Spowoduje to ponowne podłączenie HEAD do nowej gałęzi
temp
.
Następnie musisz porównać aktualne zatwierdzenie (i jego historię) z normalną gałęzią, nad którą zamierzałeś pracować:
git log --graph --decorate --pretty=oneline --abbrev-commit master origin/master temp
git diff master temp
git diff origin/master temp

(Prawdopodobnie będziesz chciał poeksperymentować z opcjami dziennika: dodaj
-p
, zostaw
--pretty = ...
, aby zobaczyć cały komunikat dziennika itp.)
Jeśli Twoja nowa gałąź
temp
wygląda dobrze, możesz zaktualizować (na przykład)
master
, aby wskazywała na nią:
git branch -f master temp
git checkout master

<sub>
(te dwa polecenia można skrócić jako
git checkout -B master temp
</sub>
)
Następnie możesz usunąć tymczasową gałąź:
git branch -d temp

Na koniec prawdopodobnie zechcesz przejrzeć odzyskaną historię:
git push origin master

Być może będziesz musiał dodać
--force
na końcu tego polecenia, aby wypchnąć, jeśli zdalna gałąź nie może być „szybko przekazana” do nowego zatwierdzenia (tj. Opróżniłeś lub nadpisałeś jakieś istniejące zatwierdzenie, lub w przeciwnym razie przepisałem trochę historii).
Jeśli byłeś w trakcie operacji rebase, prawdopodobnie powinieneś to wyczyścić. Możesz sprawdzić, czy rebase zostało zakończone, przechodząc do katalogu
.git/rebase-merge/
. Możesz ręcznie wyczyścić bieżący rebase, po prostu usuwając ten katalog (na przykład, jeśli nie pamiętasz już celu i kontekstu aktywnego rebase). Zwykle używasz
git rebase --abort
, ale robi to dodatkowe rebase, którego prawdopodobnie chcesz uniknąć (przenosi HEAD z powrotem do oryginalnej gałęzi i opróżnia ją z powrotem do oryginalnego zatwierdzenia (commit), co spowoduje cofnięcie części pracy, którą wykonaliśmy powyżej).
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Po prostu to zrób:
git checkout master

Lub, jeśli masz zmiany, które chcesz zachować, zrób to:
git checkout -b temp
git checkout -B master temp
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Natknąłem się na to pytanie i kiedy przeczytałem na górze zagłosowałem na odpowiedź:

HEAD to symboliczna nazwa aktualnie pobranego zatwierdzenia.

Pomyślałem: aha! Jeśli
HEAD
-symbolic name przy następnym zatwierdzeniu zamówienia, mogę uzgodnić ją z
master
, zmieniając ją z
master
:
git rebase HEAD master

To polecenie:
  • sprawdza
    master
  • identyfikuje rodzica
    HEAD
    zatwierdza z powrotem do punktu
    HEAD
    innego niż
    master
  • odtwarza te zatwierdzenia na górze
    master

W rezultacie wszystkie zatwierdzenia, które były w
HEAD
, ale nie w
master
, są również w
master
.
master
pozostaje sprawdzone.
Odnośnie pilota:

kilka zatwierdzeń, które zabiłem w rebase, zostało wypartych, ale nowych, popełnionych lokalnie, nie ma.

Usuniętej historii nie można już szybko przekierować przy użyciu historii lokalnej. Będziesz musiał wymusić push (
git push -f
), aby nadpisać usuniętą historię. Jeśli masz pracowników, zwykle warto z nimi skoordynować, aby wszyscy byli na tej samej stronie.
Po kliknięciu
master
na zdalnym
origin
, zdalna gałąź śledzenia
origin/master
zostanie zaktualizowana tak, aby wskazywała na to samo zatwierdzenie (zatwierdzenie) co < code> master .
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Sprawdź krótki opis odciętej głowy tutaj:
http://git-scm.com/docs/git-checkout
http://git-scm.com/docs/git-checkout
Linia poleceń do renderowania:
git branch

lub
git branch -a

otrzymasz dane wyjściowe, jak pokazano poniżej:
* (no branch)
master
branch1

* (no branch)
wskazuje, że jesteś w oddzielnej głowie.
Możesz dostać się do tego stanu, wykonując
git checkout somecommit
itp., A to ostrzeże Cię w ten sposób:

Jesteś w stanie „odłączonej głowy”. ty
możesz się rozejrzeć, eksperymentować
zmiany i zatwierdzaj je, i możesz
odrzuć wszystkie zatwierdzenia (commits), które w tym zrobisz
bez wpływu na gałęzie
wykonując jeszcze jedną kontrolę.
Jeśli chcesz utworzyć nowy oddział dla domeny
zapisz dokonane przez siebie zatwierdzenia, możesz to zrobić
to (teraz lub później) ponownie używając -b z poleceniem
sprawdzić. Przykład:
git checkout -b nazwa_nowego_gałęzi


Teraz, żeby dostać się do mistrza

:
Wykonaj
git reflog
lub po prostu
git log
i napisz swoje zatwierdzenia. Teraz zatwierdza się
git checkout master
i
git merge
.
git merge HEAD@{1}

Edytować:
Aby dodać, użyj
git rebase -i
nie tylko do usuwania/niszczenia zatwierdzeń, których nie potrzebujesz, ale także do ich edycji. Wystarczy wspomnieć o „edit” na liście zatwierdzeń (zatwierdzeń) i możesz zmienić swoje zatwierdzenie, a następnie wydać
git rebase --continue
, aby kontynuować pracę. Zapewniłoby to, że nigdy nie wejdziesz do oddzielnej HEAD.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:


Zdobądź uzbrojony commit na swojej gałęzi
>
Po prostu uruchom
git checkout -b mynewbranch
.
Następnie uruchom
git log
, a zobaczysz, że zatwierdzenie jest teraz
HEAD
w tej nowej gałęzi.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

jeśli masz tylko gałąź główną i chcesz wrócić do „tworzenia” lub funkcji, po prostu zrób to:
git checkout origin/develop

Uwaga: sprawdź

pochodzenie/rozwój

.
Jesteś w stanie

odłączenie HEAD
... Możesz się rozejrzeć, eksperymentować
zmiany i zatwierdzić je, a także możesz odrzucić wszelkie zatwierdzenia (zatwierdzenia), które w tym zrobisz
stan bez wpływu na gałęzie, wykonując kolejną kontrolę ...
następnie
git checkout -b develop

To działa :)
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jeśli chcesz wysłać do swojego aktualnie odłączonego HEAD (sprawdź wcześniej
git log
):
git push origin HEAD:master

aby popchnąć odłączoną HEAD do gałęzi głównej na początku. Jeśli push zostanie odrzucony, spróbuj najpierw
git pull origin master
, aby uzyskać zmiany z origin. Jeśli nie przejmujesz się zmianami z miejsca pochodzenia i zostaniesz odrzucony, ponieważ wykonałeś jakąś celową zmianę bazy i chcesz zastąpić źródło/wzorzec obecną gałęzią podziału - możesz to wymusić (
-f
) . W przypadku utraty dostępu do poprzednich zatwierdzeń, zawsze możesz uruchomić
git reflog
, aby zobaczyć historię ze wszystkich gałęzi.
Aby wrócić do głównej gałęzi podczas zapisywania zmian, wypróbuj następujące polecenia:
git rebase HEAD master
git checkout master

Widzieć:

Git: „Obecnie nie jest w żadnej gałęzi”. czy istnieje łatwy sposób na powrót do oddziału przy jednoczesnym zachowaniu zmian?
https://coderoad.ru/4735556/
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Znalazłem to pytanie podczas wyszukiwania hasła
Jesteś w stanie „odłączony HEAD”.
Po przeanalizowaniu tego, co zrobiłem, aby się tu dostać, w porównaniu z tym, co zrobiłem w przeszłości, stwierdziłem, że popełniłem błąd.
Mój normalny przepływ to:
git checkout master
git fetch
git checkout my-cool-branch
git pull

Tym razem właśnie to zrobiłem:
git checkout master
git fetch
git checkout origin/my-cool-branch
# You are in 'detached HEAD' state.

Problem w tym, że przypadkowo zrobiłem to:
git checkout origin/my-cool-branch

Zamiast:
git checkout my-cool-branch

Rozwiązaniem (w mojej sytuacji) było po prostu wykonanie powyższego polecenia, a następnie kontynuowanie przepływu:
git checkout my-cool-branch
git pull
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Poniższe działały dla mnie (używając tylko mastera gałęzi):
git push origin HEAD:master
git checkout master
git pull

Pierwszy popycha odłączoną HEAD w kierunku zdalnego źródła.
Drugi trafia do mistrza oddziału.
Trzeci przywraca HEAD, który zostaje dołączony do gałęzi master.
Problemy mogą pojawić się przy pierwszym poleceniu, jeśli pchnięcie zostanie odchylone. Ale to już nie będzie problem odłączonej głowy, ale będzie to spowodowane tym, że odłączona GŁOWA nie jest świadoma jakichkolwiek odległych zmian.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Właśnie dzisiaj napotkałem ten problem i jestem prawie pewien, że rozwiązałem go, wykonując:
git branch temp
git checkout master
git merge temp

Byłem na swoim komputerze służbowym, kiedy zorientowałem się, jak to zrobić, a teraz mam ten sam problem na moim komputerze osobistym. Więc będę musiał poczekać do poniedziałku, kiedy wrócę do komputera w pracy, aby zobaczyć, jak dokładnie to zrobiłem.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jeśli jesteś całkowicie pewien, że HEAD jest w dobrym stanie:
git branch -f master HEAD
git checkout master

Prawdopodobnie nie możesz naciskać na linię, ponieważ twój mistrz odszedł od linii. Jeśli jesteś pewien, że nikt inny nie korzysta z repozytorium, możesz wymusić kliknięcie:
git push -f

Najbardziej przydatne, jeśli jesteś w gałęzi funkcji, której nikt inny nie używa.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Wszystko, co musisz zrobić, to „git checkout [nazwa gałęzi]”, gdzie [nazwa gałęzi] to nazwa oryginalnej gałęzi, z której dostałeś się do stanu podzielonej głowy. To (oddzielone od asdfasdf) zniknie.
Na przykład w gałęzi „dev” pobierasz zatwierdzenie (zatwierdzenie) asdfasd14314 - & >
'git checkout asdfasd14314'

teraz jesteś w stanie oderwania głowy
„git branch” wyświetli coś takiego jak - & >
* (detached from asdfasdf)
dev
prod
stage

ale wydostać się ze stanu odłączonej głowy i wrócić do Dev ... & >
'git checkout dev'

a następnie wyświetli się lista „git branch” - & >
* dev
prod
stage

ale to jest oczywiście, jeśli nie zamierzasz utrzymywać żadnych zmian ze stanu odłączenia głowy, ale uważam, że robię to bardzo często bez zamiaru dokonywania jakichkolwiek zmian, ale spójrz tylko na poprzednie zatwierdzenie (commit)
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jak zauważył Chris, miałem następującą sytuację
git symbolic-ref HEAD
kończy się niepowodzeniem z
fatal: ref HEAD nie jest odwołaniem symbolicznym
Jednak
git rev-parse refs/heads/master
wskazał na dobre zatwierdzenie, z którego mogłem odzyskać (w moim przypadku, ostatnie zatwierdzenie, i możesz zobaczyć to zatwierdzenie za pomocą
git show [ SHA]
Zrobiłem potem wiele brudnych rzeczy, ale to, co wydaje się być naprawione, jest po prostu
git symbolic-ref HEAD refs/heads/master
A głowa jest ponownie przymocowana!
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Zamiast
git checkout origin/master
właściwie
git checkout master
wtedy
git branch
zatwierdzi twoją gałąź.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem taki problem dzisiaj, kiedy zaktualizowałem podmoduł, ale nie było go w żadnej gałęzi. Już to zrobiłem, więc nie będziesz mógł się schować, złożyć zamówienia, odpiąć. Skończyło się na tym, że wybrałem najlepszą okazję do popełnienia (popełnienia) odłączonej głowy. Więc zaraz po tym, jak popełniłem (kiedy push się nie powiódł), zrobiłem to:
git checkout master
git cherry-pick 99fe23ab

Pomyślałem: mam wolną głowę, ale chcę być na mistrzu. Zakładając, że mój stan oderwania nie różni się zbytnio od mistrza, gdybym mógł zastosować swoje zobowiązanie do mistrza, byłbym w zgodzie. To jest dokładnie to, co robi wiśnia.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Dla mnie było to tak proste, jak ponowne usunięcie lokalnego oddziału, ponieważ nie miałem żadnych lokalnych zatwierdzeń, które chciałbym przepchnąć:
Więc zrobiłem:
git branch -d branchname

A potem sprawdź ponownie oddział:
git checkout branchname
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jeśli wykonałeś wiele zatwierdzeń

nad mistrzem

i po prostu chcesz „scalić wstecz”
master
w tym miejscu (tj. chcesz, aby
master
wskazywał na
HEAD
), wtedy jednowierszowy będzie wyglądał następująco:
git checkout -B master HEAD

  • Tworzy to nową gałąź o nazwie
    master
    , nawet jeśli już istnieje (co jest jak przeniesienie
    master
    i tego właśnie chcemy).
  • Nowo utworzona gałąź będzie wskazywać na
    HEAD
    , gdzie jesteś.
  • Nowa gałąź jest wyrejestrowana, więc po tym jesteś w
    master
    .

Okazało się, że jest to szczególnie przydatne w przypadku repozytoriów składowych, które również dość często są w stanie samodzielnym.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem ten sam problem i rozwiązałem go, wykonując następujące kroki.

Jeśli chcesz zapisać zmiany

  • Najpierw musisz uruchomić
    git checkout master
    , aby powrócić do main gałąź.
  • Jeśli chcesz zapisać zmiany, po prostu uruchom
    git checkout -b changes
    i
    git checkout -B master changes


Jeśli nie potrzebujesz zmian

  • Aby usunąć wszystkie nieśledzone pliki z gałęzi, uruchom
    git clean -df
    .
  • Następnie musisz wyczyścić wszelkie niezagregowane zmiany w swoim repozytorium. Aby to zrobić, musisz uruchomić
    git checkout -
  • Na koniec musisz wyewidencjonować swoją gałąź z powrotem do gałęzi głównej za pomocą polecenia
    git checkout master
    .
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Mówiąc najprościej, odłączony stan HEAD oznacza, że

nie sprawdzasz HEAD (lub końcówki) żadnej gałęzi

.

Podaj przykład
>
Gałąź to w większości przypadków sekwencja kilku zatwierdzeń, na przykład:

Commit (commit) 1:

master-->branch_HEAD(123be6a76168aca712aea16076e971c23835f8ca)

Commit 2:

master-->123be6a76168aca712aea16076e971c23835f8ca-->branch_HEAD(100644a76168aca712aea16076e971c23835f8ca)
Jak widać powyżej, w przypadku sekwencji zatwierdzeń, gałąź wskazuje na ostatnie zatwierdzenie. Więc w tym przypadku, jeśli wyewidencjonujesz zatwierdzenie (zatwierdzenie)

123be6a76168aca712aea16076e971c23835f8ca

wtedy będziesz w stanie odłączonej głowy, ponieważ HEAD twojego oddziału wskazuje na 100644a76168aca712aea16076e971c23835f8ca

,

i technicznie sprawdzasz w HEAD żadnej gałęzi. Stąd jesteś w stanie oderwania GŁOWA.

wyjaśnienie teoretyczne
>
Na tym blogu
http://alblue.bandlem.com/2011 ... .html
jasno stwierdza
repozytorium git to repozytorium drzewa zatwierdzeń, w którym każde zatwierdzenie wskazuje na swojego przodka, przy czym każdy wskaźnik zatwierdzania jest aktualizowany, a wskaźniki do każdej gałęzi są przechowywane w podkatalogach .git/refs. Tagi są przechowywane w pliku .git/refs/tags, a gałęzie w pliku .git/refs/heads. Jeśli spojrzysz na którykolwiek z plików, zauważysz, że każdy tag odpowiada jednemu plikowi z 40-znakowym zatwierdzeniem hash i jak wyjaśnili @Chris Johnsen i @Yaroslav Nikitenko powyżej, możesz sprawdzić te linki.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Kiedy osobiście znajduję się w sytuacji, w której okazuje się, że dokonałem pewnych zmian, gdy nie jestem w
master
(tj.
HEAD
odłączony tuż nad
master
i nie ma między nimi zatwierdzeń), może to pomóc:
git stash # HEAD has same content as master, but we are still not in master
git checkout master # switch to master, okay because no changes and master
git stash apply # apply changes we had between HEAD and master in the first place
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Wpadłem w naprawdę głupi stan, wątpię, czy ktokolwiek inny uzna to za przydatne ... ale na wszelki wypadek
git ls-remote origin
0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b HEAD
6f96ad0f97ee832ee16007d865aac9af847c1ef6 refs/heads/HEAD
0d2ab882d0dd5a6db93d7ed77a5a0d7b258a5e1b refs/heads/master

które ostatecznie naprawiłem
git push origin :HEAD
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

W moim przypadku uruchomiłem
git status
i zobaczyłem, że w moim katalogu roboczym znajduje się kilka nieśledzonych plików.
Aby rebase działał, musiałem je po prostu wyczyścić (ponieważ ich nie potrzebuję).
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

To zadziałało idealnie dla mnie:
1.
git stash
, aby zapisać lokalne modyfikacje

Jeśli chcesz zrezygnować ze zmian
git clean -df
git checkout -- .

git clean usuwa wszystkie nieśledzone pliki (ostrzeżenie: chociaż nie usunie ignorowanych plików wymienionych bezpośrednio w .gitignore, może usunąć zignorowane pliki znalezione w folderach), a git checkout czyści wszelkie nieskonfigurowane zmiany.

2.
git checkout master
, aby przełączyć się na gałąź główną (zakładając, że chcesz użyć mastera)

3.
git pull
, aby pobrać ostatnie zatwierdzenie (zatwierdzenie) z głównej gałęzi

4.
git status
, aby sprawdzić, czy wszystko wygląda świetnie

On branch master
Your branch is up-to-date with 'origin/master'.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Jeśli używasz

EGit
https://www.eclipse.org/egit/
w Eclipse:
powiedzmy, że twój mistrz jest twoją główną gałęzią rozwoju
  • zatwierdzanie (zatwierdzanie) zmian w gałęzi, zwykle nowe
  • następnie pociągnij za pilota
  • następnie kliknij prawym przyciskiem myszy węzeł projektu, wybierz polecenie i wybierz opcję pokaż historię
  • następnie kliknij prawym przyciskiem myszy opcję wyboru głównego
  • jeśli Eclipse powie Ci, że istnieją dwa nadrzędne, jeden lokalny, jeden zdalny, wybierz pilota

Powinieneś wtedy móc ponownie połączyć się ze źródłem głównym.
Anonimowy użytkownik

Anonimowy użytkownik

Potwierdzenie od:

Miałem ten sam problem. Przechowuję swoje zmiany ze sobą.
git stash
i twarde resetowanie gałęzi lokalnie do poprzedniego zatwierdzenia (myślałem, że to spowodowało), a następnie wykonałem
git pull
i teraz jestem nie odrywając tej głowy. Nie zapomnij o
git stash apply
, aby ponownie wprowadzić zmiany.

Aby odpowiedzieć na pytania, Zaloguj się lub Zarejestruj się