Zresetuj gałąź repozytorium lokalnego tak, aby działała jak HEAD

Jak zresetować mój oddział lokalny, aby był taki sam jak oddział w zdalnym repozytorium?

Zrobiłem:

git reset --hard HEAD

Ale kiedy uruchomić git status,

On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
      modified:   java/com/mycompany/TestContacts.java
      modified:   java/com/mycompany/TestParser.java

Czy możesz mi powiedzieć, dlaczego mam te „zmodyfikowane”? Nie dotknąłem tych plików? Jeśli tak, chcę je usunąć.

Ustawienie gałęzi dokładnie pasującej do gałęzi zdalnej można wykonać w dwóch krokach:

git fetch origin
git reset --hard origin/master

Jeśli chcesz zapisać stan bieżącego oddziału przed zrobieniem tego (na wszelki wypadek), możesz:

git commit -a -m "Saving my work, just in case"
git branch my-saved-work

Teraz twoja praca jest zapisywana w gałęzi „moja-zapisana-praca” na wypadek, gdybyś zdecydował, że chcesz ją odzyskać (lub chcesz przejrzeć ją później lub porównać z zaktualizowanym oddziałem).

Zauważ, że w pierwszym przykładzie założono, że nazwa zdalnego repozytorium to „origin”, a gałąź o nazwie „master” w repozytorium zdalnym odpowiada aktualnie wyewidencjonowanej gałęzi w repozytorium lokalnym.

BTW, ta sytuacja, w której się znajdujesz, wygląda okropnie jak zwykły przypadek, w którym dokonano wypychania do obecnie sprawdzanej gałęzi repozytorium, które nie jest nagie. Czy ostatnio naciskałeś na lokalne repozytorium? Jeśli nie, to nie martw się - coś innego musiało spowodować, że te pliki zostaną nieoczekiwanie zmodyfikowane. W przeciwnym razie należy pamiętać, że nie zaleca się wypychania do repozytorium, które nie jest nagie (w szczególności nie do aktualnie wyewidencjonowanego oddziału).

Musiałem zrobić (rozwiązanie w zaakceptowanej odpowiedzi):

git fetch origin
git reset --hard origin/master

Śledzony przez:

git clean -f

aby usunąć lokalne pliki

Aby zobaczyć, które pliki zostaną usunięte (bez faktycznego ich usuwania):

git clean -n -f

Najpierw zresetuj do poprzednio pobranego HEADodpowiedniego odgałęzienia:

git reset --hard @{u}

Zaletą określenia @{u}lub jego pełnej formy @{upstream}jest to, że nazwa zdalnego repozytorium i gałęzi nie musi być wyraźnie określona.

Następnie w razie potrzeby usuń nieśledzone pliki, opcjonalnie również z -x:

git clean -df

Wreszcie, w razie potrzeby, uzyskaj najnowsze zmiany:

git pull

git reset --hard HEADw rzeczywistości resetuje tylko do ostatniego zatwierdzonego stanu. W takim przypadku HEAD odnosi się do HEAD twojego oddziału.

Jeśli masz kilka zatwierdzeń, to nie zadziała.

To, co prawdopodobnie chcesz zrobić, to zresetować do źródła pochodzenia lub jakkolwiek nazywane jest twoje zdalne repozytorium. Prawdopodobnie zrobiłbym coś takiego

git reset --hard origin/HEAD

Bądź jednak ostrożny. Twardych resetów nie można łatwo cofnąć. Lepiej jest postępować zgodnie z sugestiami Dana i rozgałęzić kopię zmian przed zresetowaniem.

Wszystkie powyższe sugestie są słuszne, ale często, aby naprawdę zresetować projekt, musisz również usunąć nawet pliki, które są w twoim .gitignore.

Aby uzyskać moralny odpowiednik usunięcia katalogu projektu i ponownego klonowania ze zdalnego, należy:

git fetch
git reset --hard
git clean -x -d -f

Ostrzeżenie : git clean -x -d -fjest nieodwracalne i możesz stracić pliki i dane (np. Rzeczy, których zignorowałeś .gitignore).

Użyj poniższych poleceń. Te polecenia usuwają również wszystkie nieśledzone pliki z lokalnego gita

git fetch origin
git reset --hard origin/master
git clean -d -f

Pytanie łączy tutaj dwie kwestie:

1. jak zresetować lokalną gałąź do punktu, w którym znajduje się pilot
2. jak wyczyścić obszar pomostowy (i ewentualnie katalog roboczy), tak git statusmówinothing to commit, working directory clean.

Jedna odpowiedź to:

1. git fetch --prune _{^{(opcjonalnie) Aktualizuje lokalną migawkę zdalnego repozytorium. Dalsze polecenia są tylko lokalne.}}
   git reset --hard @{upstream}_{^{Ustawia wskaźnik gałęzi lokalnej w miejscu, w którym znajduje się migawka pilota, a także ustawia indeks i katalog roboczy na pliki tego zatwierdzenia.}}
2. git clean -d --force _{^{Usuwa nieśledzone pliki i katalogi, które utrudniają gitowi powiedzenie „wyczyść katalog roboczy”.}}

To jest coś, z czym regularnie się spotykam i uogólniłem powyższy skrypt Wolfganga do pracy z dowolną gałęzią

Dodałem również monit „jesteś pewien” i informacje zwrotne

#!/bin/bash
# reset the current repository
# WF 2012-10-15
# AT 2012-11-09
# see http://stackoverflow.com/questions/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head
timestamp=`date "+%Y-%m-%d-%H_%M_%S"`
branchname=`git rev-parse --symbolic-full-name --abbrev-ref HEAD`
read -p "Reset branch $branchname to origin (y/n)? "
[ "$REPLY" != "y" ] || 
echo "about to auto-commit any changes"
git commit -a -m "auto commit at $timestamp"
if [ $? -eq 0 ]
then
  echo "Creating backup auto-save branch: auto-save-$branchname-at-$timestamp"
  git branch "auto-save-$branchname-at-$timestamp" 
fi
echo "now resetting to origin/$branchname"
git fetch origin
git reset --hard origin/$branchname

Pod warunkiem, że zdalne repozytorium jest origini że jesteś zainteresowany branch_name:

git fetch origin
git reset --hard origin/<branch_name>

Możesz także zresetować bieżącą gałąź origindo HEAD.

git fetch origin
git reset --hard origin/HEAD

Jak to działa:

git fetch origin pobiera najnowsze z pilota, bez próby scalania lub zmiany bazy danych.

Następnie git resetresetuje <branch_name>gałąź do tego, co właśnie pobrałeś. Ta --hardopcja zmienia wszystkie pliki w drzewie roboczym, aby pasowały do ​​plików w origin/branch_name.

Zrobiłem:

git branch -D master
git checkout master

całkowicie zresetować gałąź

Uwaga: należy przejść do innego oddziału, aby móc usunąć wymagany oddział

Oto skrypt automatyzujący to, co sugeruje najpopularniejsza odpowiedź ... Zobacz ulepszoną wersję obsługującą oddziały https://stackoverflow.com/a/13308579/1497139

#!/bin/bash
# reset the current repository
# WF 2012-10-15
# see /programming/1628088/how-to-reset-my-local-repository-to-be-just-like-the-remote-repository-head
timestamp=`date "+%Y-%m-%d-%H_%M_%S"`
git commit -a -m "auto commit at $timestamp"
if [ $? -eq 0 ]
then
  git branch "auto-save-at-$timestamp" 
fi
git fetch origin
git reset --hard origin/master

Jeśli miałeś problem jak ja, że ​​dokonałeś już pewnych zmian, ale teraz, z jakiegokolwiek powodu, chcesz się go pozbyć, najszybszym sposobem jest użycie git resettego w następujący sposób:

git reset --hard HEAD~2

Miałem 2 niepotrzebne zatwierdzenia, stąd numer 2. Możesz zmienić na własną liczbę zatwierdzeń, aby zresetować.

Odpowiadając na twoje pytanie - jeśli masz 5 zatwierdzeń przed zdalnym HEAD repozytorium, powinieneś uruchomić to polecenie:

git reset --hard HEAD~5

Zauważ, że utracisz wprowadzone zmiany, więc bądź ostrożny!

Poprzednie odpowiedzi zakładają, że gałąź, która ma zostać zresetowana, jest bieżącą gałęzią (wypisana). W komentarzach OP hap497 wyjaśnił, że oddział jest rzeczywiście wyewidencjonowany, ale nie jest to wyraźnie wymagane w pierwotnym pytaniu. Ponieważ jest co najmniej jedno pytanie „duplikowane”, Zresetuj gałąź całkowicie do stanu repozytorium , co nie zakłada, że ​​gałąź jest wyewidencjonowana, oto alternatywa:

Jeśli gałąź „mybranch” nie jest obecnie wyewidencjonowana, aby zresetować ją do głowy oddziału „myremote / mybranch”, możesz użyć polecenia niskiego poziomu :

git update-ref refs/heads/mybranch myremote/mybranch

Ta metoda pozostawia wypisaną gałąź bez zmian, a działające drzewo pozostaje nietknięte. Po prostu przesuwa głowę mojego oddziału do innego zatwierdzenia, niezależnie od tego, co podano jako drugi argument. Jest to szczególnie przydatne, gdy wiele gałęzi wymaga aktualizacji do nowych zdalnych głowic.

Zachowaj jednak ostrożność i używaj gitk lub podobnego narzędzia, aby dokładnie sprawdzić źródło i miejsce docelowe. Jeśli przypadkowo zrobisz to w bieżącej gałęzi (a git cię nie powstrzyma), możesz się pomylić, ponieważ zawartość nowej gałęzi nie pasuje do działającego drzewa, które się nie zmieniło (aby to naprawić, zaktualizuj gałąź ponownie, do miejsca, gdzie było wcześniej).

Z tego często korzystam:

git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;

Należy pamiętać, że jest to dobra praktyka, aby nie wprowadzać zmian do lokalnego master / rozwinąć gałąź, ale zamiast tego utworu do innego oddziału wszelkich zmian, z nazwą oddziału poprzedzany przez rodzaj zmian, na przykład feat/, chore/, fix/, itd. W ten sposób tylko trzeba ściągaj zmiany, a nie wypychaj żadnych zmian z mastera. To samo dotyczy innych gałęzi, do których przyczyniają się inni. Dlatego powyższego należy używać tylko wtedy, gdy zdarzyło się, że dokonałeś zmian w gałęzi, do których inni się zobowiązali i musisz je zresetować. W przeciwnym razie w przyszłości unikaj wypychania do gałęzi, do której inni pchają, zamiast realizacji transakcji i wypychania do tej gałęzi za pośrednictwem wypisanej gałęzi.

Jeśli chcesz zresetować swój oddział lokalny do najnowszego zatwierdzenia w gałęzi upstream, do tej pory działa dla mnie:

Sprawdź swoje piloty, upewnij się, że twój upstream i pochodzenie są zgodne z oczekiwaniami, jeśli nie zgodnie z oczekiwaniami, skorzystaj git remote add upstream <insert URL>np. Z oryginalnego repozytorium GitHub, z którego rozwidliłeś się i / lub git remote add origin <insert URL of the forked GitHub repo>.

git remote --verbose

git checkout develop;
git commit -m "Saving work.";
git branch saved-work;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force

Na GitHub możesz również pobrać gałąź o tej samej nazwie co lokalna, aby zapisać tam pracę, chociaż nie jest to konieczne, jeśli program develop origin ma takie same zmiany jak lokalna gałąź zapisanej pracy. Korzystam z gałęzi programistycznej jako przykładu, ale może to być dowolna istniejąca nazwa gałęzi.

git add .
git commit -m "Reset to upstream/develop"
git push --force origin develop

Następnie, jeśli chcesz scalić te zmiany z inną gałęzią, w której występują konflikty, zachowując zmiany w rozwoju, użyj:

git merge -s recursive -X theirs develop

Podczas użytkowania

git merge -s recursive -X ours develop

aby zachować sprzeczne zmiany w nazwie gałęzi. W przeciwnym razie użyj narzędzia do łączenia z git mergetool.

Wszystkie zmiany razem:

git commit -m "Saving work.";
git branch saved-work;
git checkout develop;
git fetch upstream develop;
git reset --hard upstream/develop;
git clean -d --force;
git add .;
git commit -m "Reset to upstream/develop";
git push --force origin develop;
git checkout branch_name;
git merge develop;

Zauważ, że zamiast upstream / develop możesz użyć skrótu zatwierdzenia, innej nazwy oddziału itp. Użyj narzędzia CLI, takiego jak Oh My Zsh, aby sprawdzić, czy twoja gałąź jest zielona, ​​wskazując, że nie ma nic do zatwierdzenia, a katalog roboczy jest czysty ( co zostało potwierdzone lub może zostać zweryfikowane przez git status). Należy pamiętać, że może to faktycznie dodać zobowiązuje porównaniu do początkowych rozwijać, czy jest coś dodawane automatycznie przez commit np diagramy UML, nagłówki licencyjne, itd., A więc w tym przypadku, można wtedy wyciągnąć zmiany na origin developcelu upstream develop, w razie potrzeby.

Odpowiedź

git clean -d -f

był niedoceniany ( -d, aby usunąć katalogi). Dzięki!

Jeśli chcesz wrócić do HEADstanu zarówno dla katalogu roboczego, jak i indeksu, powinieneś git reset --hard HEADraczej niż HEAD^. (Może to być literówka, tak jak dla pojedynczego kontra podwójnego myślnika --hard.)

Jeśli chodzi o konkretne pytanie, dlaczego pliki te mają status zmodyfikowany, wygląda na to, że wykonałeś miękki reset zamiast twardego. Spowoduje to, że pliki, które zostały zmienione w HEADzatwierdzeniu, będą wyglądały tak, jakby były przemieszczane, co jest prawdopodobnie tym, co tutaj widzisz.

Żadna ilość resetowania i czyszczenia nie miała żadnego wpływu na nieśledzone i zmodyfikowane pliki w moim lokalnym repozytorium git (wypróbowałem wszystkie powyższe opcje). Moim jedynym rozwiązaniem tego było rm lokalnego repo i sklonowanie go ze zdalnego.

Na szczęście nie miałem innych gałęzi, na których mi zależało.

xkcd: Git

Jedyne rozwiązanie, które działa we wszystkich przypadkach, które widziałem, to usuwanie i ponowne klonowanie. Może jest inny sposób, ale oczywiście ten sposób nie pozostawia szansy na pozostanie tam starego państwa, więc wolę. Bash one-liner, który możesz ustawić jako makro, jeśli często psujesz rzeczy w git:

REPO_PATH=$(pwd) && GIT_URL=$(git config --get remote.origin.url) && cd .. && rm -rf $REPO_PATH && git clone --recursive $GIT_URL $REPO_PATH && cd $REPO_PATH

* zakłada, że ​​Twoje pliki .git nie są uszkodzone

Czy zapomniałeś utworzyć gałąź funkcji i przez pomyłkę popełniłeś bezpośrednio master?

Możesz teraz utworzyć gałąź funkcji i przywrócić ustawienia główne bez wpływu na środowisko robocze (lokalny system plików), aby uniknąć uruchamiania kompilacji, testów i problemów z blokadami plików:

git checkout -b feature-branch
git branch -f master origin/master

Tylko 3 polecenia sprawią, że będzie działać

git fetch origin
git reset --hard origin/HEAD
git clean -f

Jeśli nie masz nic przeciwko zapisaniu lokalnych zmian, ale nadal chcesz zaktualizować repozytorium, aby pasowało do źródła / HEAD, możesz po prostu ukryć lokalne zmiany, a następnie pobrać:

git stash
git pull