39 Pytanie: Jak zmusić „git pull” do zastąpienia lokalnych plików?

pytanie utworzone w Sun, Dec 23, 2018 12:00 AM

Jak wymusić nadpisanie lokalnych plików na git pull?

Scenariusz jest następujący:

  • Członek zespołu modyfikuje szablony witryny, nad którą pracujemy
  • Dodają niektóre obrazy do katalogu obrazów (ale zapominają dodać je pod kontrolą źródła)
  • Wysyłają obrazy pocztą, później, do mnie
  • Dodaję obrazy pod kontrolą źródła i wypycham je do GitHub wraz z innymi zmianami
  • Nie mogą pobierać aktualizacji z GitHub, ponieważ Git nie chce nadpisywać swoich plików.

To jest błąd, który otrzymuję:

  Błąd

: nieśledzony plik drzewa roboczego „public /images /icon.gif” zostanie nadpisany przez scalenie

Jak zmusić Gita do ich zastąpienia? Osoba jest projektantem - zazwyczaj rozwiązuję wszystkie konflikty ręcznie, więc serwer ma najnowszą wersję, którą wystarczy zaktualizować na swoim komputerze.

    
6223
  1. każdy, kto to czyta i myśli, że może stracić pliki, znalazłem się w tej pozycji i znalazłem bufor Sublime Text, który mnie uratował - jeśli pracuję nad czymś, to niechcący usunie wszystko, próbując rozwiązać podobny problem lub używając odpowiedzi na to pytanie i otwierając pliki w Sublime (co jest sporą szansą), wtedy pliki będą nadal dostępne w Sublime, po prostu tam, lub w historii cofania
    2016-01-20 08: 51: 22Z
  2. git reset --hard origin/branch_to_overwrite
    2016-03-22 08: 37: 48Z
  3. po prostu wykonaj wyciąg z rozwinięcia po początkowym sprawdzeniu -b. wykonuj swoją pracę, a następnie wsuń się z powrotem.
    2018-08-22 09: 09: 33Z
  4. Krótka odpowiedź: usuń i ponownie utwórz gałąź. 1. Usuń gałąź: git branch <branch> -D 2. Zresetuj do zatwierdzenia przed konfliktem: git reset <commit> --hard 3. Utwórz ponownie gałąź: git branch <branch> 4. Ustaw śledzenie na serwerze: git --set-upstream-to=origin/<branch> <branch> 5. Pull: git pull`
    2018-09-24 08: 54: 52Z
  5. Aby zmienić wszystkie końcówki CRLF na LF, (start clean) git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .
    2019-01-17 02: 46: 59Z
30 odpowiedzi                              30                         

Ważne: Jeśli masz jakieś lokalne zmiany, zostaną utracone. Z opcją --hard lub bez niej wszystkie lokalne zatwierdzenia, które nie zostały przesunięte, zostaną utracone. [*]

Jeśli masz pliki nie śledzone przez Git (np. przesłane treści użytkownika), pliki te nie zostaną naruszone.


Myślę, że to właściwy sposób:

 
git fetch --all

Następnie masz dwie opcje:

 
git reset --hard origin/master

LUB Jeśli jesteś w innej gałęzi:

 
git reset --hard origin/<branch_name>

Wyjaśnienie:

git fetch pobiera najnowsze z pilota bez próby scalenia lub ponownego podstawienia czegokolwiek.

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


Utrzymuj aktualne lokalne zatwierdzenia

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

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

Po tym wszystkie stare zatwierdzenia będą przechowywane w new-branch-to-save-current-commits.

Niezatwierdzone zmiany

Jednak niezatwierdzone zmiany (nawet zainscenizowane) zostaną utracone. Upewnij się, że przechowujesz i zatwierdzasz wszystko, czego potrzebujesz. W tym celu możesz uruchomić następujące polecenie:

 
git stash

A następnie ponownie zastosować te niezatwierdzone zmiany:

 
git stash pop
    
8671
2018-07-17 21: 53: 17Z
  1. Uważaj! Jeśli masz lokalne rozpakowywanie, spowoduje to ich usunięcie z oddziału! To rozwiązanie utrzymuje nienaruszone pliki nie w nienaruszonym repozytorium, alezastępuje wszystko inne.
    2012-05-17 08: 18: 25Z
  2. To popularne pytanie, więc chciałbym wyjaśnić tutaj najwyższy komentarz. Właśnie wykonałem polecenia opisane w tej odpowiedzi i nie usunąłem WSZYSTKICH plików lokalnych. Tylko zdalnie śledzone pliki zostały nadpisane, a każdy plik lokalny, który został tutaj, został nietknięty.
    2012-11-22 10: 38: 05Z
  3. To zadziałało dla mnie, a moje lokalne pliki NIE zostały usunięte.
    2013-05-21 18: 16: 11Z
  4. na wypadek, gdybyś wyciągnął z repo, którego nazwa oddziału zdalnego różni się od „master”, użyj git reset --hard origin/branch-name
    2013-12-17 11: 17: 24Z
  5. Biorąc pod uwagę ilość komentarzy do tego pytania i odpowiedzi, myślę, że git powinien zawierać polecenie takie jak git pull -f
    2014-08-26 01: 33: 48Z

Spróbuj tego:

 
git reset --hard HEAD
git pull

Powinien robić to, co chcesz.

    
842
2017-01-14 15: 10: 38Z
  1. Zrobiłem to i niektóre lokalne pliki, które nie były już w repo, pozostały na dysku.
    2011-04-08 16: 00: 57Z
  2. Nie sądzę, aby było to poprawne. powyższe spowoduje scalenie, a nie nadpisanie, o które poprosiono w pytaniu: „Jak zmusić gita do nadpisania ich?” Nie mam odpowiedzi, aktualnie jej szukam .. w tej chwili przełączam się na gałąź z kodem, który chcę zachować "git checkout BranchWithCodeToKeep", a następnie wykonuję "git branch -D BranchToOverwrite" i wreszcie „git checkout -b BranchToOverwrite”. teraz będziesz miał dokładny kod z BranchWithCodeToKeep na gałęzi BranchToOverwrite bez konieczności wykonywania scalania.
    2011-07-13 10: 11: 31Z
  3. zamiast łączenia za pomocą 'git pull', spróbuj git fetch --all, a następnie 'git reset --hard origin /master'
    2012-02-21 14: 56: 54Z
  4. yep, rozwiązanie @lloydmoore działało dla mnie. Może być odpowiedzią, a nie tylko komentarzem.
    2012-11-19 09: 54: 51Z
  5. Spowoduje to zresetowanie bieżących zmian z powrotem do ostatniego zatwierdzonego rozgałęzienia. Następnie git pull łączy zmiany z najnowszej gałęzi. To zrobiło dokładnie to, co chciałem zrobić .. Dzięki!
    2014-12-05 17: 42: 09Z

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


Czasami tylko clean -f nie pomaga. Jeśli masz nieśledzone DIRECTORIES, 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 go cofnąć.

Rozważ użycie flagi -n (--dry-run) jako pierwszej. 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
...
    
430
2018-08-17 19: 32: 32Z
  1. Awesome ... Ran this przeciwko moim repozytoriom dotfiles ... W moim katalogu domowym. Dobrze, że tak naprawdę nie miałem tam nic ważnego ...
    2011-12-11 10: 35: 13Z
  2. Myślę, że opis scenariusza jasno pokazuje, że tak naprawdę nie chce wyrzucać treści. Zamiast tego chce powstrzymać git od nadpisywania plików. @Lauri, to nie powinno mieć zdarzyło się, że ludzie źle odczytali istotę opisu scenariusza - patrz moja sugestia.
    2012-02-11 23: 05: 41Z
  3. W końcu . git clean -f -d jest przydatny, gdy make clean nie wyczyści wszystkiego.
    2012-06-23 04: 32: 08Z
  4. @ crizCraig, chyba że zostaną dodane w .gitignore
    2013-06-13 06: 58: 23Z
  5. @ earthmeLon, za co możesz chcieć git clean -dfx. -x ignoruje .gitignore. Zazwyczaj twoje produkty kompilacyjne będą w .gitignore.
    2015-08-12 18: 28: 00Z

Podobnie jak Jeż myślę, że odpowiedzi są okropne. Ale choć odpowiedź Hedgehoga może być lepsza, nie sądzę, żeby była tak elegancka, jak mogłaby być. Sposób, w jaki to zrobiłem, polega na użyciu „fetch” i „merge” ze zdefiniowaną strategią. Co powinno sprawić, że lokalne zmiany zostaną zachowane, o ile nie są one jednym z plików, które próbujesz wymusić nadpisanie.

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 istnieje konflikt

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

„-X” to nazwa opcji, a „ich” to wartość tej opcji. Decydujesz się na użycie „ich” zmian, zamiast „twoich” zmian w przypadku konfliktu.

    
357
2017-02-23 13: 45: 53Z
  1. To najlepsza odpowiedź, jaką do tej pory widziałem. Nie próbowałem tego, ale w przeciwieństwie do innych odpowiedzi, nie próbuje on zbombardować wszystkich nieśledzonych plików, co z oczywistych powodów jest bardzo niebezpieczne.
    2012-05-07 09: 36: 16Z
  2. Ditto - działało to dla mnie podczas bardzo dużej korespondencji seryjnej (żądanie ściągnięcia GitHub), gdzie chciałem tylko zaakceptować to wszystko, co miałem. Dobra odpowiedź! W moim przypadku dwie ostatnie komendy to: 1) get fetch other-repo; 2) git merge -s recursive -X theirs other-repo/master
    2012-07-27 01: 44: 56Z
  3. Poprawi to wszelkie konflikty z plikami repozytoriów, a nie z lokalnymi.
    2014-12-05 11: 40: 52Z
  4. Najlepsza odpowiedź. Najwyższa zaakceptowana odpowiedź pozostawiła mnie w mojej sprawie na odłączonej głowie. Wróciłem do lokalnej gałęzi głównej i uruchomiłem git merge -X theirs origin/master
    2016-03-11 12: 46: 21Z
  5. Poczekaj ... nie ma git add * i git commit -a <more-options-here> ma taki sam efekt? Dlaczego potrzebujesz obu?
    2017-04-25 20: 41: 26Z

Zamiast robić:

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

Radzę 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 chcesz zresetować do gałęzi początkowej /głównej w prawo?

    
259
2016-09-14 09: 46: 30Z
  1. Twoja odpowiedź jest tym, czego potrzebujesz dla swojego przedstawiciela. Muszę zapytać, czy to również usuwa wszystkie nieśledzone pliki?
    2014-01-07 06: 38: 09Z
  2. Tak, większość mojego przedstawiciela pochodzi stąd :) Spowoduje to również usunięcie wszystkich nieśledzonych plików. Coś, o czym zapomniałem i boleśnie ponowniemyśląc o zaledwie 2 dni temu ...
    2014-01-09 12: 01: 15Z
  3. Zobacz komentarze do tej innej odpowiedzi: stackoverflow.com/a/8888015 /2151700
    2014-01-09 12: 02: 55Z
  4. To nie usunęło moich nieśledzonych plików; czego właściwie się spodziewam. Czy jest jakiś powód dla niektórych osób, a nie dla innych?
    2016-04-19 15: 27: 08Z
  5. Nieśledzone pliki nie mają wpływu na reset git. Jeśli chcesz je również usunąć, najpierw wykonaj git add ., przed git reset --hard
    2017-08-15 09: 12: 21Z

Wygląda na to, że najlepiej jest najpierw:

 
git clean

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

    
128
2017-01-14 15: 10: 01Z
  1. Próbowałem użyć "git clean", aby rozwiązać ten sam problem, ale go nie rozwiązał. Stan git mówi: „Twoja gałąź i„ pochodzenie /master ”są rozbieżne, odpowiednio # i mają po 2 i 9 różnych zatwierdzeń.” i git pull mówi coś podobnego do tego, co masz powyżej.
    2009-09-24 04: 25: 42Z
  2. git clean jest raczej tępym narzędziem i może wyrzucić wiele rzeczy, które możesz chcieć zachować. Lepiej usuń lub zmień nazwy plików, na które git narzeka, dopóki nie zakończy się powodzeniem.
    2010-07-02 13: 21: 35Z
  3. Nie sądzę, aby to działało ogólnie. Czy nie ma sposobu, aby w zasadzie zrobić zdalny klon git poprzez wymuszone ściąganie git?
    2010-11-29 18: 30: 01Z
  4. @ mathick: git fetch origin && git reset --hard origin/master
    2011-02-23 04: 24: 56Z
  5. Czy git clean jest najlepszą odpowiedzią tutaj? Wydaje się, że usuwanie plików niekoniecznie jest tym, czego chce OP. Poprosili o „nadpisanie lokalnych plików”, a nie usunięcie.
    2014-03-04 08: 28: 11Z

Ostrzeżenie, spowoduje to trwałe usunięcie plików, jeśli masz jakiekolwiek wpisy katalogu /* w pliku gitignore.

Niektóre odpowiedzi wydają się być okropne. Straszne w sensie tego, co stało się z @Lauri, idąc za sugestią Davida Avsajanishvili.

Raczej (git &v1.7.6):

 
git stash --include-untracked
git pull

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

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}
    
106
2018-03-07 07: 00: 46Z
  1. Nie, nie sądzę. Składowanie po prostu przenosi niezatwierdzone pliki z drogi. Powyższe także przesuwa (przechowuje) pliki, których git nie śledzi. Zapobiega to usuwaniu plików, które zostały dodane do pilota, które nie zostały jeszcze pobrane do komputera - ale zostały utworzone (!). Wszystko bez niszczenia niezatwierdzonej pracy. Mam nadzieję, że to ma sens?
    2012-03-20 23: 54: 34Z
  2. Jeśli nie masz 1.7.6, możesz naśladować --include-untracked po prostu przez chwilowe git add - całe swoje repo, a następnie natychmiast je schować.
    2012-05-01 22: 48: 15Z
  3. Zgadzam się z Hedgehog. Jeśli zrobisz tutaj popularne odpowiedzi, prawdopodobnie przekonasz się, że przypadkowo zabiłeś wiele rzeczy, których tak naprawdę nie chciałeś stracić.
    2013-01-31 21: 28: 03Z
  4. Miałem inne nieśledzone pliki - poza tym, które scalanie /ściąganie chciał nadpisać, więc to rozwiązanie działało najlepiej. git stash apply przywrócił wszystkie moje nieśledzone pliki z wyjątkiem (słusznie) tych, które już utworzono: „już istnieje, nie ma kasy”. Działa idealnie.
    2013-04-25 04: 55: 09Z
  5. To jest najczystsza odpowiedź i powinna być akceptowana. Aby zapisać trochę pisania, możesz użyć krótkiego formularza: git stash -u.
    2017-03-23 ​​08: 30: 32Z

Możesz uznać, że to polecenie jest pomocne, aby wyrzucić lokalne zmiany:

 
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
    
91
2017-01-14 15: 12: 22Z
  1. Myślę, że opis scenariusza wyjaśnia, że ​​tak naprawdę nie chce wyrzucać treści. Raczej chce powstrzymać git od nadpisywania plików. Zobacz moją sugestię.
    2012-02-11 23: 03: 53Z
  2. Chociaż ta odpowiedź może nie pasować dokładnie do opisu, to nadal uratowała mnie przed frustracją związaną z gid twiddling z powrotami karetki (zdarzenie z fałszywym autocrlfem). Kiedy git reset --hard HEAD nie pozostawia ci „nie” zmodyfikowanych plików, te flagi „-f” są bardzo pomocne. Dziękuję.
    2013-01-16 10: 28: 58Z

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

git fetch --all

, a następnie:

git reset --hard origin/master.

    
84
2018-03-21 07: 21: 12Z

Jedyną rzeczą, która dla mnie działała była:

 
git reset --hard HEAD~5

Spowoduje to cofnięcie pięciu zatwierdzeń, a następnie

 
git pull

Odkryłem, że przeglądam jak cofnąć scalanie Git .

    
57
2017-05-23 10: 31: 37Z
  1. To, co w końcu zadziałało dla mnie, kiedy wymusiłem przeniesienie gałęzi na repozytorium źródłowe i kontynuowałem konflikty scalające, kiedy próbowałem wyciągnąć go do mojego zdalnego repo ..
    2014-05-07 05: 16: 17Z
  2. Cześć, właściwie to sztuczka dla work around, ale naprawdę skuteczna. Ponieważ niektóre konflikty mogą się zdarzyć tylko w kilku zatwierdzeniach, a następnie cofnięcie 5 zatwierdzeń sprawi, że nie będzie konfliktów ze zdalnym kodem.
    2014-11-21 10: 03: 43Z

Problem z tymi wszystkimi rozwiązaniami polega na tym, że wszystkie są albo zbyt skomplikowane, albo, co jeszcze ważniejsze, usuwają wszystkie nieśledzone pliki z serwera WWW, których nie chcemy, ponieważ zawsze są potrzebne pliki konfiguracyjne które są na serwerze, a nie na repozytoriach Gittory.

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 są jakieś pliki dodawane do repozytorium i usuwa te nieśledzone pliki z lokalnego repozytorium, które mogłyby spowodować konflikty.

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

  • Wreszcie robimy ciąg aktualizacji, aby zaktualizować do najnowszej wersji, ale tym razem bez konfliktów, ponieważ nieśledzone pliki znajdujące się w repozytorium już nie istnieją i wszystkie lokalnie zmodyfikowane pliki są już takie same jak w repozytorium.

52
2014-05-23 21: 14: 30Z
  1. Używanie "git merge origin /master" jako ostatniej linii (jak mówisz w notatce) zamiast "git pull" będzie szybsze, jak już wyciągnąłeś wszelkie zmiany w repozytorium git.
    2013-05-06 06: 21: 24Z
  2. Tak, oczywiście git merge origin/master będzie szybszy i prawdopodobnie jeszcze bezpieczniejszy. Ponieważ jeśli ktoś usunął nowe zmiany podczas usuwania plików tego skryptu (co prawdopodobnie się nie wydarzy, ale możliwe), cały ciąg może się nie powieść. Jedynym powodem, dla którego wprowadziłem pull, jest to, że ktoś może nie pracować na gałęzi głównej, ale na innej gałęzi i chciałem, aby skrypt był uniwersalny.
    2013-09-01 22: 25: 37Z
  3. Jeśli masz lokalnie utworzone pliki, takie jak pliki opcji, umieść je w .gitignore.
    2017-11-21 11: 41: 39Z

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

Rozwiązałem go przez:

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

Teraz działa.

    
42
2019-01-18 23: 00: 30Z
  1. To samo tutaj. Czasami działa tylko bardzo trudne rozwiązanie, często zdarza się, że tylko resetowanie i czyszczenie nie wystarczą ...
    2011-12-15 11: 28: 09Z

    Przede wszystkim spróbuj w 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 nie masz ich zatwierdzonych! Jeśli nie masz pewności, zrób kopię zapasową całego folderu repozytorium.

    Następnie pociągnij go ponownie.

    Jeśli powyższe nie pomoże, a nie obchodzą Cię twoje nieśledzone pliki /katalogi (najpierw wykonaj kopię zapasową na wszelki wypadek), spróbuj następujących prostych kroków:

     
    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 wyłączeniem .git/ katalogów, w których znajdują się wszystkie zatwierdzenia) i pociągnięcie go ponownie.


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

    1. Niestandardowe reguły w .gitattributes file

      Posiadanie reguły eol=lf w .gitattributes może spowodować, że git zmodyfikuje niektóre zmiany plików, konwertując zakończenia linii CRLF na LF w niektórych plikach tekstowych.

      Jeśli tak jest, musisz zatwierdzić 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

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

      Jak zauważyłeś, istnieją dwa różne systemy plików, więc ten, który nie obsługuje uprawnień Unix, zasadniczo nie może zresetować uprawnień do plików w systemie, który nie obsługuje tego rodzaju uprawnień, więc bez względu na to, jak --hard próbujesz, git zawsze wykrywa niektóre „zmiany”.

    41
    2019-01-31 15: 48: 34Z

    Bonus:

    Mówiąc o pull /fetch /merge w poprzednich odpowiedziach, chciałbym podzielić się ciekawą i produktywną sztuczką,

    git pull --rebase

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

    Przed wypchnięciem twojego nowego zatwierdzenia na serwer, spróbuj tego polecenia i automatycznie zsynchronizuje ostatnie zmiany serwera (z fetch + merge) i umieści twoje zatwierdzenie na górze w dzienniku Git. Nie ma potrzeby martwić się o ręczne ściąganie /scalanie.

    Znajdź szczegóły w Co robi „git pull --rebase”? .

        
    35
    2018-04-27 13: 02: 41Z

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

 
git reset --hard HEAD
git clean -f
git pull
    
27
2011-11-06 16: 35: 34Z
  1. ostrożnie użyj git clean
    2012-03-30 16: 39: 22Z

Bazując na podobnych doświadczeniach, rozwiązanie oferowane przez Strahinja Kustudic powyżej jest zdecydowanie najlepsze. Jak zauważyli inni, po prostu wykonanie twardego resetu usunie wszystkie nieśledzone pliki, które mogą zawierać wiele rzeczy, których nie chcesz usunąć, takich jak pliki konfiguracyjne. Bezpieczniejsze jest usunięcie tylko tych plików, które mają zostać dodane, i prawdopodobnie warto też sprawdzić wszystkie pliki zmodyfikowane lokalnie, które mają zostać zaktualizowane.

Mając to na uwadze, zaktualizowałem skrypt Kustudica, aby to właśnie zrobił. Naprawiłem też literówkę (brakującą 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
    
27
2015-08-13 23: 12: 27Z
  1. Używanie "git merge origin /master" jako ostatniej linii (jak mówisz w notatce) zamiast "git pull" będzie szybsze, jak już wyciągnąłeś wszelkie zmiany w repozytorium git.
    2013-05-06 06: 20: 47Z
  2. Konieczne jest pobranie zmodyfikowanych plików, więc działa to 100% razy. Zaktualizowałem mój skrypt już dawno temu, ale zapomniałem również zaktualizować tutaj. Używam go także trochę inaczej niż ty. Sprawdzam pliki, które mają jakikolwiek rodzaj modyfikacji, nie tylko M, więc działa cały czas.
    2013-09-01 22: 48: 40Z

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 jest bardzo wydajny, więc możesz stracić zmiany.

    
27
2017-01-14 15: 42: 28Z
  1. Spowoduje to nadpisanie zmodyfikowanych plików (plików, które zostały wcześniej zaewidencjonowane) i usunie nieśledzone pliki (pliki, które nigdy nie zostały zaewidencjonowane). Dokładnie to, czego szukałem, dzięki!
    2016-03-03 16: 01: 46Z
  2. Podejrzewam, że trzecia linia git reset --hard HEAD może być zbędna; moja lokalna strona man (2.6.3) mówi, że reset w drugiej linii git reset --hard origin/master „domyślnie przyjmuje HEAD we wszystkich formach.”
    2016-04-19 15: 40: 52Z
  3. @ arichards Myślę, że twój podejrzany ma rację, ale jeśli druga linia nie zadziała (z jakiegokolwiek powodu) trzecia linia działa dobrze do zresetowania. To rozwiązanie nie wymaga optymalizacji. Właśnie podsumowałem inne odpowiedzi. To wszystko. Tdziękuję za komentarz. :)
    2016-04-20 02: 12: 45Z

Sądzę, że istnieją dwie możliwe przyczyny konfliktu, które muszą zostać rozwiązane oddzielnie, a o ile wiem, żadna z powyższych odpowiedzi nie dotyczy obu:

  • Pliki lokalne, które nie są śledzone, należy usunąć ręcznie (bezpieczniej) lub zgodnie z sugestiami innych odpowiedzi, git clean -f -d

  • Lokalne zatwierdzenia, które nie znajdują się w oddziale zdalnym, również muszą zostać usunięte. IMO najłatwiejszym sposobem osiągnięcia tego jest: git reset --hard origin/master (zastąp 'master' niezależnie od gałęzi, nad którą pracujesz, i uruchom najpierw git fetch origin)

23
2011-12-12 20: 05: 07Z

Wygląda na to, że większość odpowiedzi tutaj koncentruje się na gałęzi master; jednak zdarzają się sytuacje, w których pracuję nad tą samą gałęzią funkcji w dwóch różnych miejscach i chcę, aby rebase w jednej była odzwierciedlona w drugiej, bez przeskakiwania obręczy.

W oparciu o połączenie odpowiedzi RNA i odpowiedź Tarka na podobne pytanie , wymyśliłem to, co działa znakomicie:

 
git fetch
git reset --hard @{u}

Uruchom to z oddziału i zresetuje tylko lokalny oddział do wersji wstępnej.

Można to ł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}"

Ciesz się!

    
20
2017-05-23 12: 18: 32Z
  1. Ta odpowiedź jest również ładna, ponieważ działa niezależnie od tego, w której gałęzi jesteś!
    2018-09-11 20: 14: 56Z

Łatwiejszym sposobem byłoby:

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

To nadpisze twój lokalny plik plikiem git

    
20
2015-05-05 08: 03: 29Z

Miałem ten sam problem iz jakiegoś powodu nawet git clean -f -d tego nie zrobił. Oto dlaczego: Z jakiegoś powodu, jeśli twój plik jest ignorowany przez Git (zakładam, że jest to wpis .gitignore), nadal niepokoi go nadpisanie tego późniejszym ciągiem , ale wyczyszczenie nie usunie go, chyba że dodasz -x.

    
19
2015-03-18 19: 46: 19Z

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

 
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 podaje listę zmian lokalnych. Kontynuuj modyfikowanie gałęzi „tmp”, aż będzie akceptowalna, a następnie połącz z powrotem na master za pomocą:

 
git checkout master && git merge tmp

Następnym razem prawdopodobnie będziesz w stanie to zrobić w bardziej przejrzysty sposób, wyszukując „gałąź git stash”, chociaż skrytka prawdopodobnie sprawi ci kłopoty w pierwszych kilku próbach, więc najpierw eksperymentuj nad niekrytycznym projektem. .

    
18
2017-01-14 15: 13: 29Z

Mam dziwną sytuację, że ani git clean, ani git reset nie działa. Muszę usunąć konfliktowy plik z git index, używając następującego skryptu w każdym nieśledzonym pliku:

 
git rm [file]

Wtedy jestem w stanie wykonać wszystko dobrze.

    
17
2017-12-05 04: 35: 20Z

Wiem o znacznie łatwiejszej i mniej bolesnej metodzie:

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

To wszystko!

    
17
2018-09-05 16: 52: 42Z

Te cztery polecenia działają dla mnie.

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

Sprawdzanie /ściąganie po wykonaniu tych poleceń

 
git pull origin master

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

    
13
2014-03-20 04: 24: 02Z
  1. "git branch -D master" usuwa gałąź. więc bądź ostrożny z tym. Wolę używać „git checkout origin /master -b < new branch name >” które tworzą nową gałąź z nową nazwą, a ty potrzebujesz 3,4 linii. Zaleca się również użycie „git clean -f”.
    2014-04-05 11: 49: 57Z

Pomimo pierwotnego pytania najlepsze odpowiedzi mogą powodować problemy dla osób, które mają podobny problem, ale nie chcą tracić lokalnych plików. Zobacz na przykład komentarze Al-Punk i crizCraig.

Następująca wersja zatwierdza lokalne zmiany w tymczasowej gałęzi (tmp), sprawdza oryginalną gałąź (którą zakładam jest master) i łączy aktualizacje. Możesz to zrobić za pomocą stash, ale odkryłem, że zwykle łatwiej jest po prostu użyć podejścia rozgałęzienia /scalenia.

 
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.

    
13
2015-03-18 19: 43: 07Z

Po prostu wykonaj

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

Więc unikniesz wszelkich niepożądanych efektów ubocznych, takich jak usuwanie plików lub katalogów, które chciałeś zachować itp.

    
12
2017-01-14 15: 48: 47Z

Zresetuj indeks i głowę do origin/master, ale nie resetuj drzewa roboczego:

 
git reset origin/master
    
11
2013-02-15 13: 41: 43Z
  1. Osobiście uznałem to za najbardziej przydatne. Następnie utrzymuje twoje drzewo robocze, abyś mógł je ponownie sprawdzić. W moim przypadku usunąłem te same pliki, które zostały dodane, więc utknęły. Dziwne, wiem.
    2014-01-04 21: 03: 59Z

Przeczytałem wszystkie odpowiedzi, ale szukałem pojedynczego 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 polecenie jako

 
git fp origin master

odpowiednik

 
git fetch origin master
git reset --hard origin/master
    
9
2016-07-08 13: 11: 14Z

Wymagania:

  1. Śledź zmiany lokalne, aby nikt tutaj ich nie stracił.
  2. Ustaw lokalne repozytorium jako zgodne ze zdalnym repozytorium pochodzenia.

Rozwiązanie:

  1. Ukryj lokalne zmiany.
  2. Pobierz z czystym plikami i katalogami ignorującymi .gitignore i twardy reset do początku .

     
    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    
9
2017-01-14 15: 44: 53Z
źródło umieszczone tutaj