⚠ Ważne: jeśli masz jakieś zmiany lokalne, zostaną one utracone. Z opcją --hard lub bez niej wszelkie lokalne zatwierdzenia, które nie zostały przekazane, zostaną utracone.^[*]

Jeśli masz jakieś pliki, które nie są śledzone przez Git (np. przesłane treści użytkowników), nie będzie to miało wpływu na te pliki.

Najpierw uruchom pobieranie, aby zaktualizować wszystkie origin/<branch> referencje do najnowszych:

git fetch --all

Utwórz kopię zapasową bieżącego oddziału:

git branch backup-master

Następnie masz dwie opcje:

git reset --hard origin/master

LUB Jeśli jesteś w innym oddziale:

git reset --hard origin/<branch_name>

Wyjaśnienie:

git fetch pobiera najnowszą wersję ze zdalnego komputera, bez konieczności łączenia lub zmiany bazy.

Następnie git reset resetuje gałąź główną do tego, co właśnie pobrałeś. Opcja --hard zmienia wszystkie pliki w drzewie roboczym tak, aby pasowały do ​​plików w origin/master

Utrzymuj bieżące zobowiązania lokalne

^[*]: Warto zauważyć, że możliwe jest utrzymanie bieżących zatwierdzeń lokalnych poprzez utworzenie gałęzi z master przed zresetowaniem:

git checkout master
git branch new-branch-to-save-current-commits
git fetch --all
git reset --hard origin/master

Następnie wszystkie stare zatwierdzenia zostaną zachowane w new-branch-to-save-current-commits.

Niezatwierdzone zmiany

Jednak niezatwierdzone zmiany (nawet przestawione) zostaną utracone. Pamiętaj, aby przechowywać i zatwierdzać wszystko, czego potrzebujesz. W tym celu możesz uruchomić następujące czynności:

git stash

A następnie, aby ponownie zastosować te niezatwierdzone zmiany:

git stash pop

Spróbuj tego:

git reset --hard HEAD
git pull

Powinno robić to, co chcesz.

OSTRZEŻENIE: git clean usuwa wszystkie nieśledzone pliki/katalogi i nie można tego cofnąć.

Czasami samo clean -f nie pomaga. Jeśli nie śledzisz KATALOGÓW, potrzebna jest również opcja -d:

# WARNING: this can't be undone!

git reset --hard HEAD
git clean -f -d
git pull

OSTRZEŻENIE: git clean usuwa wszystkie nieśledzone pliki/katalogi i nie można tego cofnąć.

Rozważ najpierw użycie flagi -n (--dry-run). To pokaże Ci, co zostanie usunięte, bez faktycznego usuwania czegokolwiek:

git clean -n -f -d

Przykładowe wyjście:

Would remove untracked-file-1.txt
Would remove untracked-file-2.txt
Would remove untracked/folder
...

Podobnie jak Jeż, myślę, że odpowiedzi są okropne. Ale chociaż odpowiedź Hedgehoga może być lepsza, nie sądzę, że jest tak elegancka, jak mogłaby być. Sposób, w jaki udało mi się to zrobić, polega na użyciu fetch i merge ze zdefiniowaną strategią. Co powinno sprawić, że lokalne zmiany zostaną zachowane, o ile nie są jednym z plików, którymi próbujesz wymusić zastąpienie.

Najpierw wykonaj zatwierdzenie zmian

 git add *
 git commit -a -m "local file server commit message"

Następnie pobierz zmiany i zastąp je, jeśli wystąpi konflikt

 git fetch origin master
 git merge -s recursive -X theirs origin/master

-X to nazwa opcji, a theirs to wartość tej opcji. Decydujesz się na użycie their zmian (druga opcja to ours zmian), jeśli wystąpi konflikt.

Zamiast robić:

git fetch --all
git reset --hard origin/master

Radziłbym wykonać następujące czynności:

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

Nie musisz pobierać wszystkich pilotów i gałęzi, jeśli masz zamiar zresetować do gałęzi Origin/Master, prawda?

Wygląda na to, że najlepszym sposobem jest najpierw:

git clean

Aby usunąć wszystkie nieśledzone pliki i kontynuować zwykłe git pull...

Uwaga, wykonanie tej czynności spowoduje trwale usuń swoje pliki, jeśli masz jakieś wpisy w katalogu/* w pliku gitignore.

Niektóre odpowiedzi wydają się okropne. Straszne w sensie tego, co przydarzyło się @Lauri, postępując zgodnie z sugestią Davida Avsajanishvili.

Raczej (git > v1.7.6):

git stash --include-untracked
git pull

Później możesz wyczyścić historię skrytki.

Ręcznie, jeden po drugim:

$ git stash list
stash@{0}: WIP on <branch>: ...
stash@{1}: WIP on <branch>: ...

$ git stash drop stash@{0}
$ git stash drop stash@{1}

Brutalnie, wszystko na raz:

$ git stash clear

Oczywiście, jeśli chcesz wrócić do tego, co ukryłeś:

$ git stash list
...
$ git stash apply stash@{5}

To polecenie może okazać się przydatne do wyrzucenia lokalnych zmian:

git checkout <your-branch> -f

A następnie wykonaj czyszczenie (usuwa nieśledzone pliki z drzewa roboczego):

git clean -f

Jeśli chcesz usunąć nieśledzone katalogi oprócz nieśledzonych plików:

git clean -fd

Zamiast łączyć się z git pull, spróbuj tego:

git fetch --all

śledzony przez:

git reset --hard origin/master.

Jedyne, co dla mnie zadziałało, to:

git reset --hard HEAD~5

Spowoduje to cofnięcie się o pięć zatwierdzeń, a następnie

git pull

Znalazłem to, sprawdzając jak cofnąć połączenie Git.

Problem ze wszystkimi tymi rozwiązaniami polega na tym, że są albo zbyt skomplikowane, albo, co jest jeszcze większym problemem, polega na tym, że usuwają wszystkie nieśledzone pliki z serwera WWW, czego nie chcemy, ponieważ zawsze są potrzebne pliki konfiguracyjne, które są włączone na serwerze, a nie w repozytorium Git.

Oto najczystsze rozwiązanie, którego używamy:

# Fetch the newest code
git fetch

# Delete all files which are being added, so there
# are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    rm -f -- "$file"
done

# Checkout all files which were locally modified
for file in `git diff --name-status | awk '/^[CDMRTUX]/ {print $2}'`
do
    git checkout -- "$file"
done

# Finally pull all the changes
# (you could merge as well e.g. 'merge origin/master')
git pull

• Pierwsze polecenie pobiera najnowsze dane.

• Drugie polecenie sprawdza, czy do repozytorium są dodawane jakieś pliki i usuwa te nieśledzone pliki z lokalnego repozytorium, które mogłyby powodować konflikty.

• Trzecie polecenie sprawdza wszystkie pliki, które zostały lokalnie zmodyfikowane.

• Na koniec wykonujemy aktualizację do najnowszej wersji, ale tym razem bez żadnych konfliktów, ponieważ nieśledzone pliki znajdujące się w repozytorium już nie istnieją, a wszystkie lokalnie zmodyfikowane pliki są już takie same jak w repozytorium.

Na początek wypróbuj standardowy sposób:

git reset HEAD --hard # To remove all not committed changes!
git clean -fd         # To remove all untracked (non-git) files and folders!

^{Ostrzeżenie: powyższe polecenia mogą spowodować utratę danych/plików tylko wtedy, gdy ich nie zatwierdzisz! Jeśli nie masz pewności, wykonaj najpierw kopię zapasową całego folderu repozytorium.}

Następnie pociągnij ponownie.

Jeśli powyższe nie pomoże i nie przejmujesz się nieśledzonymi plikami/katalogami (na wszelki wypadek najpierw wykonaj kopię zapasową), spróbuj wykonać następujące proste kroki:

cd your_git_repo  # where 'your_git_repo' is your git repository folder
rm -rfv *         # WARNING: only run inside your git repository!
git pull          # pull the sources again

Spowoduje to USUNIĘCIE wszystkich plików git (z wyjątkiem .git/ katalogu, w którym masz wszystkie zatwierdzenia) i pociągnięcie ich ponownie.

Dlaczego git reset HEAD --hard może w niektórych przypadkach zawieść?

1. Niestandardowe reguły w .gitattributes file

   Posiadanie reguły eol=lf w .gitattributes może spowodować, że git zmodyfikuje niektóre zmiany w plikach poprzez konwersję końcówek linii CRLF na LF w niektórych plikach tekstowych.

   W takim przypadku musisz zatwierdzić te zmiany CRLF/LF (przeglądając je w git status) lub spróbować: git config core.autcrlf false, aby je tymczasowo zignorować.

2. Niezgodność systemu plików

   Kiedy używasz systemu plików, który nie obsługuje atrybutów uprawnień. Na przykład masz dwa repozytoria, jedno w systemie Linux/Mac (ext3/hfs+), a drugie w systemie plików opartym na FAT32/NTFS.

   Jak zauważyłeś, istnieją dwa różne rodzaje systemów plików, więc ten, który nie obsługuje uprawnień Unixa, w zasadzie nie może zresetować uprawnień do plików w systemie, który nie obsługuje tego rodzaju uprawnień, więc niezależnie od tego, jak --hard spróbujesz, git zawsze wykrywa pewne „zmiany”.

Miałem ten sam problem. Nikt nie dał mi tego rozwiązania, ale zadziałało dla mnie.

Rozwiązałem to poprzez:

1. Usuń wszystkie pliki. Pozostaw tylko katalog .git.
2. git reset --hard HEAD
3. git pull
4. git push

Teraz działa.

Premia:

Mówiąc o ściąganiu/pobieraniu/scalaniu w poprzednich odpowiedziach, chciałbym podzielić się interesującą i produktywną sztuczką,

git pull --rebase

Powyższe polecenie jest najbardziej użytecznym poleceniem w moim życiu Git, które pozwoliło zaoszczędzić dużo czasu.

Zanim wypchniesz swoje nowe zatwierdzenie na serwer, wypróbuj to polecenie, a ono automatycznie zsynchronizuje najnowsze zmiany na serwerze (pobranie + połączenie) i umieści twoje zatwierdzenie na górze dziennika Git. Nie ma potrzeby martwić się o ręczne ściąganie/scalanie.

Więcej szczegółów znajdziesz w Co robi git pull --rebase?.

Miałem podobny problem. Musiałem to zrobić:

git reset --hard HEAD
git clean -f
git pull

Podsumowałem inne odpowiedzi. Możesz wykonać git pull bez błędów:

git fetch --all
git reset --hard origin/master
git reset --hard HEAD
git clean -f -d
git pull

Ostrzeżenie: ten skrypt ma bardzo duże możliwości, więc możesz utracić wprowadzone zmiany.

Bazując na moich własnych, podobnych doświadczeniach, powyższe rozwiązanie oferowane przez Strahinję Kustudic jest zdecydowanie najlepsze. Jak zauważyli inni, zwykłe wykonanie twardego resetu spowoduje usunięcie wszystkich nieśledzonych plików, które mogą zawierać wiele rzeczy, których nie chcesz usuwać, takich jak pliki konfiguracyjne. Bezpieczniejsze jest usunięcie tylko plików, które mają zostać dodane, a jeśli o to chodzi, prawdopodobnie warto także pobrać wszystkie pliki zmodyfikowane lokalnie, które mają zostać zaktualizowane.

Mając to na uwadze, zaktualizowałem skrypt Kustudica, aby właśnie to zrobić. Poprawiłem także literówkę (brakujące „w oryginale”).

#/bin/sh

# Fetch the newest code
git fetch

# Delete all files which are being added,
# so there are no conflicts with untracked files
for file in `git diff HEAD..origin/master --name-status | awk '/^A/ {print $2}'`
do
    echo "Deleting untracked file $file..."
    rm -vf "$file"
done

# Checkout all files which have been locally modified
for file in `git diff HEAD..origin/master --name-status | awk '/^M/ {print $2}'`
do
    echo "Checking out modified file $file..."
    git checkout $file
done

# Finally merge all the changes (you could use merge here as well)
git pull

Uważam, że istnieją dwie możliwe przyczyny konfliktu, które należy rozwiązać osobno i o ile wiem, żadna z powyższych odpowiedzi nie dotyczy obu:

• Lokalne pliki, które nie są śledzone, należy usunąć ręcznie (bezpieczniej) lub zgodnie z sugestią w innych odpowiedziach do git clean -f -d

• Lokalne zatwierdzenia, które nie znajdują się w zdalnej gałęzi, również muszą zostać usunięte. IMO najłatwiej to osiągnąć za pomocą: git reset --hard origin/master (zamień „master” na dowolną gałąź, nad którą pracujesz, i najpierw uruchom git fetch origin)

Wygląda na to, że większość odpowiedzi koncentruje się na gałęzi master; jednak zdarza się, że pracuję nad tą samą gałęzią funkcji w dwóch różnych miejscach i chcę, aby zmiana bazy w jednym znalazła odzwierciedlenie w drugim, bez częstego przeskakiwania przez przeszkody.

Na podstawie kombinacji odpowiedzi RNA i odpowiedź Torka na podobne pytanie, wymyśliłem coś, co działa znakomicie:

git fetch
git reset --hard @{u}

Uruchom to z oddziału, a to zresetuje tylko twój lokalny oddział do wersji nadrzędnej.

Można to również ładnie umieścić w aliasie git (git forcepull):

git config alias.forcepull "!git fetch ; git reset --hard @{u}"

Lub w pliku .gitconfig:

[alias]
  forcepull = "!git fetch ; git reset --hard @{u}"

Cieszyć się!

Miałem ten sam problem i z jakiegoś powodu nawet git clean -f -d by tego nie zrobił. Oto dlaczego: Z jakiegoś powodu, jeśli Twój plik jest ignorowany przez Gita (zakładam, że poprzez wpis .gitignore), nadal przeszkadza to w zastąpieniu go późniejszym ściągnięciem, ale czystym nie usunie go, chyba że dodasz -x.

Łatwiejszym sposobem byłoby:

git checkout --theirs /path/to/file.extension
git pull origin master

Spowoduje to zastąpienie Twojego pliku lokalnego plikiem na git

Znam znacznie łatwiejszą i mniej bolesną metodę:

$ git branch -m [branch_to_force_pull] tmp
$ git fetch
$ git checkout [branch_to_force_pull]
$ git branch -D tmp

Otóż ​​to!

Właśnie rozwiązałem to sam:

git checkout -b tmp # "tmp" or pick a better name for your local changes branch
git add -A
git commit -m 'tmp'
git pull
git checkout master # Or whatever branch you were on originally
git pull
git diff tmp

gdzie ostatnie polecenie wyświetla listę zmian lokalnych. Kontynuuj modyfikowanie gałęzi „tmp”, aż będzie akceptowalna, a następnie wróć do mastera za pomocą:

git checkout master && git merge tmp

Następnym razem prawdopodobnie poradzisz sobie z tym w czystszy sposób, wyszukując „gałąź git stash”, chociaż skrytka prawdopodobnie sprawi ci problemy przy pierwszych kilku próbach, więc najpierw przeprowadź eksperyment na niekrytycznym projekcie…

Mam dziwną sytuację, w której ani git clean, ani git reset nie działają. Muszę usunąć powodujący konflikt plik z git index, używając następującego skryptu na każdym nieśledzonym pliku:

git rm [file]

Wtedy jestem w stanie dobrze ciągnąć.

Używać:

git fetch --all

Jeśli jesteś w gałęzi master,

git reset --hard origin/master

w przeciwnym razie

git reset --hard origin/master<branch_name>

Po prostu zrób

git fetch origin branchname
git checkout -f origin/branchname // This will overwrite ONLY new included files
git checkout branchname
git merge origin/branchname

Dzięki temu unikasz wszelkich niepożądanych skutków ubocznych, takich jak usuwanie plików lub katalogów, które chciałeś zachować itp.

Pomimo pierwotnego pytania, najlepsze odpowiedzi mogą powodować problemy dla osób, które mają podobny problem, ale nie chcą stracić swoich plików lokalnych. Na przykład zobacz komentarze Al-Punk i crizCraiga.

Następująca wersja zatwierdza lokalne zmiany w gałęzi tymczasowej (tmp), sprawdza oryginalną gałąź (zakładam, że to master) i łączy aktualizacje. Można to zrobić za pomocą stash, ale odkryłem, że zwykle łatwiej jest po prostu zastosować podejście rozgałęziające/scalające.

git checkout -b tmp
git add *; git commit -am "my temporary files"
git checkout master

git fetch origin master
git merge -s recursive -X theirs origin master

gdzie zakładamy, że inne repozytorium to origin master.

Zresetuj indeks i nagłówek do origin/master, ale nie resetuj drzewa roboczego:

git reset origin/master

Te cztery polecenia działają dla mnie.

git reset --hard HEAD
git checkout origin/master
git branch -D master
git checkout -b master

Aby sprawdzić/wyciągnąć po wykonaniu tych poleceń

git pull origin master

Dużo próbowałem, ale w końcu udało mi się wykonać te polecenia.

Wymagania:

1. Śledź lokalne zmiany, aby nikt ich nigdy nie zgubił.
2. Dopasuj lokalne repozytorium do zdalnego repozytorium pochodzenia.

Rozwiązanie:

1. Ukryj zmiany lokalne.

2. Pobierz z czystym plikami i katalogami, ignorując .gitignore i twardy reset do Origin.

   git stash --include-untracked
   git fetch --all
   git clean -fdx
   git reset --hard origin/master
   

Przeczytałem wszystkie odpowiedzi, ale szukałem jednego polecenia, aby to zrobić. Oto co zrobiłem. Dodano alias git do .gitconfig

[alias]
      fp = "!f(){ git fetch ${1} ${2} && git reset --hard ${1}/${2};};f"

Uruchom swoje polecenie jako

git fp origin master

równoważny

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

To zadziałało dla mnie bardzo dobrze!

git fetch --all
git reset --hard origin/master

Oto najlepsza praktyka przywracania zmian:

• git commit Zatwierdź wprowadzone zmiany, aby zostały zapisane w reflogu (patrz poniżej)
• git fetch Pobierz najnowsze zmiany z źródła
• git reset --hard origin/master Twardy reset do głównej gałęzi Origin

reflog zapisuje gałęzie i inne odniesienia, które są aktualizowane w lokalnym repozytorium. Mówiąc prościej – reflog to historia Twoich zmian.

Dlatego zawsze warto się zaangażować. Zatwierdzenia są dołączane do reflogu, dzięki czemu zawsze będziesz mieć możliwość odzyskania usuniętego kodu.

Nie używaj git reset --hard. To usunie ich zmiany, które mogą być całkowicie niepożądane. Zamiast:

git pull
git reset origin/master
git checkout <file1> <file2> ...

Możesz oczywiście użyć git fetch zamiast git pull, ponieważ wyraźnie nie zamierza się połączyć, ale jeśli zwykle ciągniesz, sensowne jest kontynuowanie ciągnięcia tutaj.

Dzieje się tak dlatego, że git pull aktualizuje Twoje źródło/odniesienie główne; git reset aktualizuje numer referencyjny lokalnego oddziału tak, aby był taki sam jak Origin/master bez aktualizacji jakichkolwiek plików, więc stan wyewidencjonowania pozostaje niezmieniony; następnie git checkout przywraca pliki do stanu indeksu oddziału lokalnego, jeśli zajdzie taka potrzeba. W przypadkach, gdy dokładnie ten sam plik został dodany na serwerze głównym i na serwerze nadrzędnym, indeks jest już zgodny z plikiem po zresetowaniu, więc w typowym przypadku nie trzeba w ogóle wykonywać git checkout.

Jeśli gałąź nadrzędna zawiera również zatwierdzenia, które chcesz zastosować automatycznie, możesz zastosować subtelną odmianę tego procesu:

git pull
git merge <commit before problem commit>
git reset <problem commit>
git checkout <file1> <file2> ...
git pull

Możesz spróbować:

$ git fetch --all
$ git reset --hard origin/master 
$ git pull

Użyłem tego polecenia, aby pozbyć się plików lokalnych uniemożliwiających mi wykonanie ściągania/scalania. Ale bądź ostrożny! Najpierw uruchom git merge …, aby sprawdzić, czy są tylko te pliki, które naprawdę chcesz usunąć.

git merge origin/master 2>&1 >/dev/null | grep ^[[:space:]] | sed s/^[[:space:]]//g | xargs -L1 rm

• git merge wymienia między innymi wszystkie te pliki. Są one poprzedzone spacją.
• 2>&1 >/dev/null przekierowuje wyjście błędu na standardowe, więc jest ono odbierane przez grep.
• grep ^[[:space:]] filtruje tylko linie z nazwami plików.
• sed s/^[[:space:]]//g przycina odstęp od początku.
• xargs -L1 rm wywołuje rm na każdym z tych plików, usuwając je.

Zachowaj ostrożność: niezależnie od wyników git merge, rm zostanie wywołane dla każdej linii zaczynającej się od spacji.

Próbowałem użyć gałęzi Material2 na Angular2-Webpack-Starter i świetnie się bawiłem. Tylko w ten sposób mogłem pobrać tę gałąź i używać jej.

git clone --depth 1 https://github.com/angularclass/angular2-webpack-starter.git

cd angular2-webpack-starter/

git checkout -b material2

Otwórz folder projektu i usuń wszystkie nieukryte pliki i foldery. Zostaw wszystkie ukryte.

git add .

git commit -m "pokemon go"

git reset --hard

git pull origin material2

(Kiedy pojawi się edytor, naciśnij „:wq”, a następnie naciśnij Enter)

Teraz jesteś gotowy.

Jeśli chcesz zresetować do gałęzi zdalnego śledzenia w sposób ogólny, użyj:

git fetch
git reset --keep origin/$(git rev-parse --abbrev-ref HEAD)

Jeśli chcesz także zresetować zmiany lokalne:

git fetch
git reset --hard origin/$(git rev-parse --abbrev-ref HEAD)

W systemie Windows wykonaj to pojedyncze polecenie:

git fetch --all & git reset --hard origin/master

Możesz zignorować ten plik z plikiem w folderze podstawowym projektu:

.gitignore

public/images/*

Następnie pociągnij zmiany, a następnie usuń tę linię z pliku gitignore.

1: Reset do poprzedniego zatwierdzenia

git reset --hard HEAD

2: Usuń nieśledzone pliki

git clean -f

3: Wyciągnij zatwierdzenia

git pull

Źródła:

• https://git-scm.com/docs/git-reset
• https://git-scm.com/docs/git-clean/

Pomimo faktu, że na to pytanie istnieje już wiele odpowiedzi, pierwotnym pytaniem jest rozwiązanie tego pytania

błąd: Nieśledzony plik drzewa roboczego „public/images/icon.gif” zostałby nadpisany przez połączenie

Ponieważ plików binarnych nie można łączyć, prosta odpowiedź brzmi

git checkout public/images/icon.gif

Dzięki temu plik odzyska poprzedni stan, jaki miał w tej gałęzi.

Zwykle tak robię git stash, jeśli nie chcę stracić zmian, lub coś w rodzaju git checkout ., jeśli nie interesują mnie pliki modyfikowane lokalnie. IMO o wiele prostsze niż reset --hard, clean... i wszystkie te rzeczy lepiej nadają się do opuszczenia gałęzi jak w trybie zdalnym, w tym zatwierdzenia, nieśledzone pliki, a nie tylko rozwiązywanie lokalnie zmodyfikowanego pliku.

Gdy wykonasz git pull, otrzymasz listę plików, które nie pasują. Jeśli liczba plików nie jest zbyt duża, możesz je pobrać, ta akcja spowoduje nadpisanie tych plików.

git checkout -- ‹nazwa pliku›

Zwykle to robię, jeśli w celu szybkiego sprawdzenia modyfikuję pliki lokalne na serwerze (nie jest to zalecane i prawdopodobnie powód pojawienia się tego problemu :D), sprawdzam zmienione pliki po znalezieniu rozwiązania.

Zrobiłem to, aby to zadziałało:

Na komputerze, na którym utworzyłem nowy oddział:

git push --all

Na komputerze, na którym chciałem, aby nowy oddział wyświetlał:

git fetch --all

Krok 1. (opcjonalnie)
W katalogu głównym lokalnego repozytorium zapisz kopię zapasową i opróżnij bieżący folder:

mkdir -p ../<branch>-bkp && mv --backup=t * ../<branch>-bkp

Krok 2. Pobierz wszystkie pliki i foldery oddziału ze zdalnego repozytorium:

git checkout <branch> && git add -A . && git reset --hard origin/<branch> && git pull

gdzie należy zastąpić <branch> nazwą gałęzi, którą chcesz zastąpić.

Komentarze:

• Zamiast kroku 1 wolisz ręcznie wykonać kopię zapasową i usunąć bieżące pliki i foldery.
  polecam robiąc to za pomocą modułu obsługi plików w interfejsie GUI systemu operacyjnego.
• Jeśli pominiesz krok 1, uważaj: utracisz całą pracę w lokalnym repozytorium!
• Ważne: jeśli pominiesz git pull w kroku 2,
  ryzykujesz, że nie otrzymasz najnowszej wersji od zdalne repozytorium!
  Zgodnie z drugim odnośnikiem poniżej, git reset --hard
  zresetuje obszar przejściowy i katalog roboczy, aby dopasować je do najnowszego zatwierdzenia .
  Moje doświadczenie zaprzecza temu twierdzeniu!
• Jeśli uruchomisz git reset --hard origin/<branch_to_overwrite> bez uprzedniego usunięcia wszystkich plików i folderów z lokalnego repozytorium, uważaj, ponieważ wszelkie niepotrzebne pliki, które wciąż się znajdują, mogą później przedostać się do zdalnego repozytorium git push, nawet jeśli nie było to Twoim zamiarem.
  Dodatkowe git add -A . w krok 2 zapobiega temu, jeśli zdecydujesz się pominąć krok 1.

Referencje:
https://gitforwindows.org/
https://www.atlassian.com/git/tutorials/undoing-changes/git-reset
https://www.atlassian.com/git/tutorials/rewriting-history/git-reflog

Ponieważ często potrzebuję szybkiego sposobu na zresetowanie bieżącej gałęzi w systemie Windows za pomocą wiersza poleceń, oto szybki sposób:

for /f "tokens=1* delims= " %a in ('git branch^|findstr /b "*"') do @git reset --hard origin/%b

Wypróbowałem większość tego, co mogłem tutaj znaleźć, żaden nie zadziałał w moim przypadku.

To, co zadziałało, to git merge -X theirs

Możesz spróbować git pull --force lub może ukryć swoje zatwierdzenia, używając git stash, a następnie uruchamiając git pull.

Myślę, że możesz też wymusić git push -f / git push --force