Jak wymusić zastąpienie plików lokalnych w pliku git pull?

Scenariusz jest następujący:

• Członek zespołu modyfikuje szablony witryny, nad którą pracujemy
• Dodają kilka obrazów do katalogu obrazów (ale zapomina dodać je pod kontrolą źródła)
• Później wysyłają mi zdjęcia pocztą
• 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 zastępować swoich plików.

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

błąd: nieśledzony plik drzewa roboczego „public / images / icon.gif” zostałby zastąpiony przez scalenie

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

Ważne: jeśli wprowadzisz jakieś zmiany lokalne, zostaną one utracone. Z --hardopcją lub bez , wszelkie lokalne zatwierdzenia, które nie zostały wypchnięte, 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.

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 innym oddziale:

git reset --hard origin/<branch_name>

Wyjaśnienie:

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

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

Utrzymuj bieżące lokalne zobowiązania

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

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

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

Niezatwierdzone zmiany

Niezatwierdzone zmiany zostaną jednak utracone. Pamiętaj, aby schować i popełnić 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

Powinien robić, co chcesz.

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

Czasami po prostu clean -fnie pomaga. W przypadku nieśledzonych DIRECTORIES -d również potrzebna jest opcja:

# WARNING: this can't be undone!

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

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

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

git clean -n -f -d

Przykładowe dane wyjściowe:

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ź Jeża może być lepsza, nie sądzę, aby była tak elegancka, jak mogłaby być. Znalazłem to, używając „pobierania” i „scalania” ze zdefiniowaną strategią. Co powinno sprawić, że lokalne zmiany zostaną zachowane, o ile nie będą to jeden z plików, które próbujesz wymusić nadpisaniem.

Najpierw wykonaj zatwierdzenie swoich 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 „ich” to wartość tej opcji. Zdecydujesz się użyć „ich” zmian, zamiast „swoich” zmian w przypadku konfliktu.

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 źródła / gałęzi głównej, prawda?

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

git clean

Aby usunąć wszystkie nieśledzone pliki, a następnie kontynuować zwykłe git pull...

Uwaga, zrobienie tego spowoduje trwałe usunięcie plików, jeśli masz jakieś wpisy katalogu / * w pliku gitignore.

Niektóre odpowiedzi wydają się okropne. Straszne w tym, co się stało z @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ę zapasów.

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, od razu:

$ 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 pomóc w odrzuceniu lokalnych zmian:

git checkout <your-branch> -f

A następnie wykonaj czyszczenie (usuwa nieśledzone pliki z działającego drzewa):

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 działało dla mnie, to:

git reset --hard HEAD~5

Spowoduje to powrót do pięciu zatwierdzeń, a następnie z

git pull

Zauważyłem, że patrząc na to, jak cofnąć scalenie Git .

Problem z tymi wszystkimi rozwiązaniami polega na tym, że wszystkie są albo zbyt skomplikowane, albo, jeszcze większy problem, 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 serwer, a nie 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 zmodyfikowane lokalnie.

• Wreszcie staramy się zaktualizować 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.

Najpierw 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 kopię zapasową na pierwszym miejscu w całym folderze repozytorium.}

Następnie pociągnij ponownie.

Jeśli powyższe nie pomoże i nie obchodzi Cię nieśledzone pliki / katalogi (wykonaj kopię zapasową na wszelki wypadek), 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 (wyłącz katalog .git/, w którym masz wszystkie zatwierdzenia) i ściągniesz je ponownie.

Dlaczego git reset HEAD --hardw niektórych przypadkach może się nie powieść?

1. Niestandardowe reguły w .gitattributes file

   Mający eol=lf reguły w .gitattributes może spowodować, że git zmodyfikuje niektóre zmiany pliku, przekształcając zakończenia linii CRLF w LF w niektórych plikach tekstowych.

   W takim przypadku należy zatwierdzić zmiany CRLF / LF (przeglądając je git status) lub spróbować: git config core.autcrlf falsetymczasowo je 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 w systemie plików 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ń uniksowych, 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 --hardspróbujesz, git zawsze wykrywaj „zmiany”.

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

Rozwiązałem to przez:

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

Teraz działa.

Premia:

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

git pull --rebase

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

Przed wypchnięciem nowego zatwierdzenia na serwer, wypróbuj to polecenie, a ono automatycznie zsynchronizuje najnowsze zmiany na serwerze (z funkcją pobierania + scalania) i umieści zatwierdzenie na górze w dzienniku Git. Nie musisz martwić się ręcznym ściąganiem / scalaniem.

Znajdź szczegóły w Czym zajmuje się „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 pullbez 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.

W oparciu o moje własne podobne doświadczenia, rozwiązanie oferowane przez Strahinja Kustudic powyżej jest zdecydowanie najlepsze. Jak zauważyli inni, zwykły twardy reset usunie wszystko nieśledzone pliki, które mogą zawierać wiele rzeczy, których nie chcesz usuwać, takich jak pliki konfiguracyjne. Bezpieczniejsze jest usuwanie tylko plików, które mają zostać dodane, i w związku z tym prawdopodobnie będziesz również chciał pobrać wszystkie lokalnie zmodyfikowane pliki, które mają zostać zaktualizowane.

Mając to na uwadze, zaktualizowałem skrypt Kustudica, aby to zrobić. Naprawił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:

• Pliki lokalne, które nie są śledzone, muszą zostać usunięte ręcznie (bezpieczniej) lub zgodnie z sugestią w innych odpowiedziach autorstwa git clean -f -d

• Lokalne zatwierdzenia, które nie znajdują się w oddziale zdalnym, również muszą zostać usunięte. IMO najprostszym sposobem na osiągnięcie tego jest: git reset --hard origin/master(zamień „master” na jakąkolwiek gałąź, nad którą pracujesz, i uruchom git fetch originpierwszą)

Łatwiejszym sposobem byłoby:

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

Spowoduje to zastąpienie lokalnego pliku plikiem w git

Wygląda na to, że większość odpowiedzi tutaj dotyczy mastergałęzi; są jednak chwile, kiedy pracuję nad tą samą gałęzią funkcji w dwóch różnych miejscach i chcę, aby podstawa w jednym była odzwierciedlona w drugim, bez dużej ilości skoków przez obręcze.

Oparty na kombinacji odpowiedzi RNA i odpowiedzi torek do podobnych pytanie , mam wymyślić ten, który działa wspaniale:

git fetch
git reset --hard @{u}

Uruchom to z oddziału, a spowoduje to zresetowanie lokalnego oddziału do wersji nadrzędnej.

Można to również dobrze umieścić w git alias ( git forcepull):

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

Lub w twoim .gitconfigpliku:

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

Cieszyć się!

Miałem ten sam problem iz jakiegoś powodu nawet git clean -f -dtego nie zrobiłbym. Oto dlaczego: Z jakiegoś powodu, jeśli twój plik jest ignorowany przez Git (zakładam, że za pomocą wpisu .gitignore), nadal kłopota się nadpisaniem go późniejszym ściągnięciem , ale czysty nie usunie go, chyba że dodasz -x.

Znam dużo ł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 przez:

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ę lokalnych zmian. Kontynuuj modyfikowanie gałęzi „tmp”, aż będzie to akceptowalne, a następnie ponownie połącz z master:

git checkout master && git merge tmp

Następnym razem możesz prawdopodobnie poradzić sobie z tym w bardziej przejrzysty sposób, patrząc na „gałąź git stash”, chociaż skrytka może powodować problemy w pierwszych kilku próbach, więc najpierw eksperymentuj nad niekrytycznym projektem ...

Mam dziwną sytuację, że żadna git cleanlub git resetrobót. Muszę usunąć plik powodujący konflikt, git indexużywając następującego skryptu na każdym nieśledzonym pliku:

git rm [file]

Jestem w stanie dobrze pociągnąć.

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

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

Następująca wersja zatwierdza lokalne zmiany w gałęzi tymczasowej ( tmp), sprawdza oryginalną gałąź (którą zakładam, że jest master) i łączy aktualizacje. Możesz to zrobić za pomocą stash, ale stwierdziłem, że zwykle łatwiej jest po prostu użyć metody 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 drugie repozytorium znajduje się 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ć / pociągnąć po wykonaniu tych poleceń

git pull origin master

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

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 unikniesz wszystkich niepożądanych efektów ubocznych, takich jak usuwanie plików lub katalogów, które chcesz zachować itp.

Zresetuj indeks i nagłówek do origin/master, ale nie resetuj działającego drzewa:

git reset origin/master

Wymagania:

1. Śledź lokalne zmiany, aby nikt ich nie zgubił.
2. Dopasuj lokalne repozytorium do zdalnego źródłowego repozytorium.

Rozwiązanie:

1. Ukryj lokalne zmiany.

2. Fetch z czysty z plików i katalogów ignorując .gitignore i twardy reset do pochodzenia .

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