Jak całkowicie zastąpić oddział lokalny oddziałem zdalnym w Git?

Mam dwa oddziały:

1. oddział lokalny (ten, z którym pracuję)
2. oddział zdalny (publiczny, tylko dobrze przetestowane commity tam)

Ostatnio poważnie popsułem mój lokalny oddział.

Jak całkowicie zastąpić oddział lokalny oddziałem zdalnym, aby móc kontynuować pracę z miejsca, w którym znajduje się teraz oddział zdalny?

Już przeszukałem SO i lokalne sprawdzenie w oddziale zdalnym nie ma żadnego efektu.

1. Upewnij się, że sprawdziłeś gałąź, którą zastępujesz (na podstawie komentarza Zoltána ).

2. Zakładając, że master jest lokalną gałęzią, którą zastępujesz, a „origin / master” to gałąź zdalna, którą chcesz zresetować:

   git reset --hard origin/master
   

Spowoduje to zaktualizowanie lokalnej gałęzi HEAD do tej samej wersji co origin / master i --hardzsynchronizuje tę zmianę również z indeksem i obszarem roboczym.

To tak proste, jak trzy kroki:

1. Usuń swój lokalny oddział: git branch -d local_branch
2. Pobierz najnowszą zdalną gałąź: git fetch origin remote_branch
3. Odbuduj oddział lokalny na podstawie zdalnego: git checkout -b local_branch origin/remote_branch

git branch -D <branch-name>
git fetch <remote> <branch-name>
git checkout -b <branch-name> --track <remote>/<branch-name>

Zastąp wszystko zdalnym oddziałem; ale tylko z tego samego zatwierdzenia, w którym działa Twój oddział lokalny:

git reset --hard origin/some-branch

LUB uzyskaj najnowsze informacje ze zdalnego oddziału i zamień wszystko:

git fetch origin some-branch
git reset --hard FETCH_HEAD

Na bok, w razie potrzeby, możesz usunąć nieśledzone pliki i katalogi, których jeszcze nie dopuściłeś:

git clean -fd

Najbezpieczniejszy i najbardziej kompletny sposób zastąpienia obecnego oddziału lokalnego pilotem:

git stash
git merge --abort
git rebase --abort
git branch -M yourBranch replaced_yourBranch
git fetch origin yourBranch:yourBranch
git checkout yourBranch

stashLinia zapisuje zmiany, które nie zostały popełnione. branchLinia przenosi swój oddział do innej nazwy, zwalniając oryginalną nazwę. fetchLinia pobiera najnowszą kopię pilocie. checkoutLinia odtwarza oryginalny oddział jako oddział śledzenia.

Lub jako funkcja bash:

replaceWithRemote() {
    yourBranch=${1:-`git rev-parse --abbrev-ref HEAD`}
    git stash
    git merge --abort
    git rebase --abort
    git branch -M ${yourBranch} replaced_${yourBranch}_`git rev-parse --short HEAD`
    git fetch origin ${yourBranch}:${yourBranch}
    git checkout ${yourBranch}
}

która zmienia nazwę bieżącej gałęzi na coś takiego jak replace_master_98d258f.

Jestem trochę zaskoczony, że nikt jeszcze o tym nie wspominał; Używam go prawie codziennie:

git reset --hard @{u}

Zasadniczo @{u}jest to tylko skrót dla gałęzi upstream, którą śledzi twoja obecna gałąź. Na przykład zwykle jest to równe origin/[my-current-branch-name]. To miłe, ponieważ jest agnostyczne dla gałęzi.

git fetchNajpierw upewnij się, aby uzyskać najnowszą kopię zdalnego oddziału.

Można to zrobić na wiele sposobów, kontynuując edycję tej odpowiedzi w celu rozpowszechnienia lepszej perspektywy wiedzy.

1) Zresetuj mocno

Jeśli pracujesz ze zdalnej gałęzi rozwoju, możesz zresetować HEAD do ostatniego zatwierdzenia na zdalnej gałęzi, jak poniżej:

git reset --hard origin/develop

2) Usuń bieżącą gałąź i ponownie dokonaj płatności ze zdalnego repozytorium

Biorąc pod uwagę, że pracujesz nad rozwojem oddziału w lokalnym repozytorium, który synchronizuje się ze zdalnym / develop oddziału, możesz wykonać następujące czynności:

git branch -D develop
git checkout -b develop origin/develop

3) Przerwij scalanie

Jeśli znajdujesz się pomiędzy złym scaleniem (błędnie zrobionym z niewłaściwą gałęzią) i chciałeś uniknąć scalenia, aby wrócić do gałęzi najpóźniej jak poniżej:

git merge --abort

4) Przerwij wycofanie

Jeśli jesteś pomiędzy złym rebase, możesz przerwać żądanie rebase, jak poniżej:

git rebase --abort

Możesz zrobić, jak powiedział @ Hugo z @Laurent, lub możesz użyć git rebasedo usunięcia zatwierdzeń, które chcesz się pozbyć, jeśli wiesz, które. Zazwyczaj używam git rebase -i head~N(gdzie N jest liczbą, umożliwiającą manipulowanie ostatnimi N zatwierdzeniami) do tego rodzaju operacji.

Wybrana odpowiedź jest absolutnie poprawne , jednakże nie zostawił mnie ostatni commit / naciska ...

Więc dla mnie:

git reset --hard dev/jobmanager-tools
git pull  ( did not work as git was not sure what branch i wanted)

Ponieważ wiem, że chcę tymczasowo ustawić moją gałąź nadrzędną na kilka tygodni na konkretną gałąź (taką samą jak ta, którą przełączyłem / wylogowałem wcześniej i dokonałem twardego resetu)

Więc PO zresetowaniu

git branch --set-upstream-to=origin/dev/jobmanager-tools
git pull
git status    ( says--> on branch  dev/jobmanager-tools 

Jeśli chcesz zaktualizować gałąź, która nie jest obecnie wyewidencjonowana, możesz:

git fetch -f origin rbranch:lbranch

Jak podano w wybranym objaśnieniu, git reset jest dobry. Ale obecnie często używamy podmodułów: repozytoriów w repozytoriach. Na przykład, jeśli używasz ZF3 i jQuery w swoim projekcie, najprawdopodobniej chcesz, aby zostały one sklonowane z ich oryginalnych repozytoriów. W takim przypadku reset git nie wystarczy. Musimy zaktualizować submoduły do ​​dokładnie tej wersji, która jest zdefiniowana w naszym repozytorium:

git checkout master
git fetch origin master
git reset --hard origin/master
git pull

git submodule foreach git submodule update

git status

jest to to samo, co rekursywnie będziesz wchodził (cd) do katalogu roboczego każdego podmodułu i będzie działał:

git submodule update

I to bardzo różni się od

git checkout master
git pull

ponieważ podmoduły wskazują nie rozgałęzienie, ale zatwierdzenie.

W takich przypadkach, gdy ręcznie wyewidencjonujesz jakiś oddział dla 1 lub więcej submodułów, możesz uruchomić

git submodule foreach git pull

git reset --hard
git clean -fd

To działało dla mnie - clean pokazał także wszystkie pliki, które usunął. Jeśli powie ci, że stracisz zmiany, musisz się schować.

Brzydki, ale prostszy sposób: usuń folder lokalny i ponownie sklonuj zdalne repozytorium.