39 Domanda: Come impongo "git pull" per sovrascrivere i file locali?

domanda creata a Sun, Dec 23, 2018 12:00 AM

Come impongo una sovrascrittura di file locali su un git pull?

Lo scenario segue:

  • Un membro del team sta modificando i modelli per un sito web su cui stiamo lavorando
  • Aggiungono alcune immagini alla directory delle immagini (ma si dimentica di aggiungerle sotto il controllo del codice sorgente)
  • Stanno inviando le immagini per posta, più tardi, a me
  • Sto aggiungendo le immagini sotto il controllo del codice sorgente e inserendole in GitHub insieme ad altre modifiche
  • Non possono estrarre gli aggiornamenti da GitHub perché Git non vuole sovrascrivere i loro file.

Questo è l'errore che sto ottenendo:

  

errore: il file dell'albero di lavoro non tracciato "public /images /icon.gif" verrebbe sovrascritto dall'unione

Come faccio a forzare Git a sovrascriverli? La persona è un designer - di solito risolvo tutti i conflitti a mano, quindi il server ha la versione più recente che devono solo aggiornare sul proprio computer.

    
6223
  1. chiunque legga questo chi pensa che potrebbero perdere i file, sono stato in questa posizione e ho trovato il buffer di Sublime Text mi ha salvato - se sto lavorando su qualcosa, allora cancella accidentalmente tutto cercando di risolvere un problema simile a questo o usando una risposta a questa domanda e hai avuto i file aperti in Sublime (che c'è una buona possibilità di) quindi i file saranno ancora lì è Sublime, o solo lì, o nella cronologia degli annullamenti
    2016-01-20 08: 51: 22Z
  2. git reset --hard origin/branch_to_overwrite
    2016-03-22 08: 37: 48Z
  3. in pratica, esegui solo un pull da sviluppare dopo il checkout iniziale -b. fai il tuo lavoro, quindi torna indietro.
    2018-08-22 09: 09: 33Z
  4. Risposta breve: cancella e ricrea il ramo. 1. Elimina ramo: git branch <branch> -D 2. Ripristina un commit prima del conflitto: git reset <commit> --hard 3. Ricrea il ramo: git branch <branch> 4. Imposta il monitoraggio sul server: git --set-upstream-to=origin/<branch> <branch> 5. Pull: git pull`
    2018-09-24 08: 54: 52Z
  5. Per cambiare tutti i finali da CRLF a LF, (avvia clean) git config core.autocrlf false; git ls-files -z | xargs -0 rm; git checkout .
    2019-01-17 02: 46: 59Z
30 risposte                              30                         

Importante: se si verificano cambiamenti locali, questi andranno persi. Con o senza l'opzione --hard, qualsiasi commit locale che non è stato premuto verrà perso. [*]

Se hai file non monitorati da Git (ad esempio contenuti utente caricati), questi file non saranno interessati.


Penso che questo sia il modo giusto:

 
git fetch --all

Quindi hai due opzioni:

 
git reset --hard origin/master

OPPURE Se ti trovi su qualche altro ramo:

 
git reset --hard origin/<branch_name>

Spiegazione:

git fetch scarica l'ultima versione dal remoto senza tentare di unire o rebase nulla.

Quindi il git reset reimposta il ramo master su ciò che hai appena recuperato. L'opzione --hard cambia tutti i file nella struttura di lavoro in modo che corrispondano ai file in origin/master


Mantieni i commit locali correnti

[*] : vale la pena notare che è possibile mantenere i commit locali correnti creando un ramo da master prima di resettare:

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

Dopo questo, tutti i vecchi commit saranno mantenuti in new-branch-to-save-current-commits.

Modifiche non applicate

Le modifiche non applicate, tuttavia (anche messe in scena), andranno perse. Assicurati di mettere da parte e salvare tutto ciò di cui hai bisogno. Per questo è possibile eseguire quanto segue:

 
git stash

E poi riapplicare queste modifiche senza commit:

 
git stash pop
    
8671
2018-07-17 21: 53: 17Z
  1. Attenzione! Se hai impegni locali non spinti, questo li rimuoverà dal tuo ramo! Questa soluzione mantiene intatti i file non tracciati non presenti nel repository, ma sovrascrive semprealtro.
    2012-05-17 08: 18: 25Z
  2. È una domanda popolare, quindi mi piacerebbe chiarire il commento più importante qui. Ho appena eseguito i comandi come descritto in questa risposta e non ha rimosso TUTTI i file locali. Solo i file tracciati in remoto sono stati sovrascritti e ogni file locale che è stato qui non è stato toccato.
    2012-11-22 10: 38: 05Z
  3. Questo ha funzionato per me e i miei file locali NON sono stati cancellati.
    2013-05-21 18: 16: 11Z
  4. nel caso in cui stai prelevando da un repository che ha il suo nome di diramazione remoto diverso da "master", usa git reset --hard origin/branch-name
    2013-12-17 11: 17: 24Z
  5. Data la quantità di uptotes a questa domanda e risposta, penso che git dovrebbe incorporare un comando come git pull -f
    2014-08-26 01: 33: 48Z

Prova questo:

 
git reset --hard HEAD
git pull

Dovrebbe fare quello che vuoi.

    
842
2017-01-14 15: 10: 38Z
  1. Ho fatto questo e alcuni file locali che non erano più in repo sono stati lasciati sul disco.
    2011-04-08 16: 00: 57Z
  2. Non penso che sia corretto. quanto sopra eseguirà una fusione, non una sovrascrittura, che è stata richiesta nella domanda: "Come forzare la git a sovrascriverli?" Non ho la risposta, al momento lo sto cercando .. al momento passo al ramo con il codice che voglio mantenere "git checkout BranchWithCodeToKeep", quindi "git branch -D BranchToOverwrite" e infine "git checkout -b BranchToOverwrite". ora avrai il codice esatto da BranchWithCodeToKeep sul ramo BranchToOverwrite senza dover eseguire un'unione.
    2011-07-13 10: 11: 31Z
  3. invece di fondere usando 'git pull', prova git fetch --all seguito da 'git reset --hard origin /master'
    2012-02-21 14: 56: 54Z
  4. sì, la soluzione @lloydmoore ha funzionato per me. Potrebbe essere una risposta piuttosto che un semplice commento.
    2012-11-19 09: 54: 51Z
  5. Questo ripristinerà le modifiche correnti sull'ultimo commit del ramo estratto. Quindi git pull unisce le modifiche dall'ultimo ramo. Questo ha fatto esattamente quello che volevo che facesse .. Grazie!
    2014-12-05 17: 42: 09Z

ATTENZIONE: il git clean elimina tutti i file /directory non tracciati e non può essere annullato.


A volte solo clean -f non aiuta. Nel caso in cui tu abbia DIRECTORY non tracciati, anche l'opzione -d ha bisogno di:

 
# WARNING: this can't be undone!

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

ATTENZIONE: il git clean elimina tutti i file /directory non tracciati e non può essere annullato.

Considerare prima di usare il flag -n (--dry-run). Questo ti mostrerà ciò che verrà eliminato senza effettivamente eliminare nulla:

 
git clean -n -f -d

Esempio di output:

 
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 ... Ho usato questo contro il mio repository dotfiles ... Nella mia home directory. Bene, non avevo davvero niente di importante lì ...
    2011-12-11 10: 35: 13Z
  2. I tla descrizione dello scenario fa capire chiaramente che non vuole davvero buttare via il contenuto. Piuttosto ciò che vuole è smettere di git baulking per sovrascrivere i file. @Lauri, questo non dovrebbe essere successo a te. Sfortunatamente le persone sembrano aver frainteso l'essenza della descrizione dello scenario - guarda il mio suggerimento
    2012-02-11 23: 05: 41Z
  3. FINALMENTE . git clean -f -d è utile quando make clean non riesce a pulire tutto.
    2012-06-23 04: 32: 08Z
  4. @ crizCraig a meno che non vengano aggiunti in .gitignore
    2013-06-13 06: 58: 23Z
  5. @ earthmeLon, per questo potresti volere git clean -dfx. Il -x ignora .gitignore. In genere i tuoi prodotti di costruzione saranno in .gitignore.
    2015-08-12 18: 28: 00Z

Come Riccio penso che le risposte siano terribili. Ma anche se la risposta di Hedgehog potrebbe essere migliore, non penso che sia così elegante come potrebbe essere. Il modo in cui ho trovato di farlo è utilizzando "fetch" e "merge" con una strategia definita. Il che dovrebbe fare in modo che le modifiche locali vengano mantenute purché non siano uno dei file con cui si tenta di forzare una sovrascrittura.

Prima esegui il commit delle tue modifiche

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

Quindi recupera le modifiche e sovrascrive se c'è un conflitto

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

"- X" è un nome di opzione e "loro" è il valore per tale opzione. Stai scegliendo di utilizzare le "loro" modifiche, invece delle "tue" modifiche in caso di conflitto.

    
357
2017-02-23 13: 45: 53Z
  1. Questa è la migliore risposta che ho visto finora. Non l'ho provato, ma a differenza di altre risposte, questo non tenta di applicare il nuke a tutti i file non tracciati, il che è molto pericoloso per ovvi motivi.
    2012-05-07 09: 36: 16Z
  2. Idem: questo ha funzionato per me quando si esegue una fusione molto grande (richiesta pull GitHub) in cui volevo semplicemente accettare tutto ciò che avevo sopra. Buona risposta! Nel mio caso gli ultimi due comandi erano: 1) get fetch other-repo; 2) git merge -s recursive -X theirs other-repo/master
    2012-07-27 01: 44: 56Z
  3. Questo sovrascriverà qualsiasi conflitto con i file repository e non quelli locali, corretto?
    2014-12-05 11: 40: 52Z
  4. Risposta migliore. La risposta più alta accettata mi ha lasciato nel mio caso sulla testa staccata. Sono tornato al ramo principale locale e ho eseguito git merge -X theirs origin/master
    2016-03-11 12: 46: 21Z
  5. Aspetta ... non ha git add * e git commit -a <more-options-here> hanno lo stesso effetto? Perché avresti bisogno di entrambi?
    2017-04-25 20: 41: 26Z

Invece di fare:

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

Consiglierei di fare quanto segue:

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

Non è necessario recuperare tutti i telecomandi e le derivazioni se si intende ripristinare la diramazione origine /master?

    
259
2016-09-14 09: 46: 30Z
  1. La tua risposta è proprio ciò che ti serviva per il tuo rappresentante. Devo chiedere, questo rimuove anche tutti i file non tracciati?
    2014-01-07 06: 38: 09Z
  2. Sì, la maggior parte del mio rappresentante proviene da qui :) Questo rimuoverà anche tutti i file non tracciati. Qualcosa che avevo dimenticato e ricordato dolorosamente solo 2 giorni fa ...
    2014-01-09 12: 01: 15Z
  3. Vedi i commenti su quest'altra risposta: stackoverflow.com/a/8888015 /2151700
    2014-01-09 12: 02: 55Z
  4. Questo non ha rimosso i miei file non tracciati; che è in realtà ciò che mi aspetterei. C'è una ragione che potrebbe essere per alcune persone e non per gli altri?
    2016-04-19 15: 27: 08Z
  5. I file non tracciati non sono influenzati da git reset. Se vuoi che vengano rimossi, fai prima il git add ., prima del git reset --hard
    2017-08-15 09: 12: 21Z

Sembra che il modo migliore sia fare prima:

 
git clean

Per eliminare tutti i file non tracciati e quindi continuare con il solito git pull ...

    
128
2017-01-14 15: 10: 01Z
  1. Ho provato a utilizzare "git clean" per risolvere lo stesso problema, ma non lo risolve. lo stato di git dice "Il tuo ramo e 'origine /padrone' sono divergenti, # e hanno 2 e 9 commit diversi rispettivamente." e git pull dice qualcosa di simile a quello che hai sopra.
    2009-09-24 04: 25: 42Z
  2. git clean è uno strumento piuttosto ottuso e potrebbe buttare via molte cose che potresti voler mantenere. Meglio rimuovere o rinominare i file di cui git si lamenta fino a quando il pull ha esito positivo.
    2010-07-02 13: 21: 35Z
  3. Non penso che funzioni in generale. Non c'è un modo per fare fondamentalmente un clone git remoto tramite un pull git forzato?
    2010-11-29 18: 30: 01Z
  4. @ mathick: git fetch origin && git reset --hard origin/master
    2011-02-23 04: 24: 56Z
  5. git clean è la migliore risposta qui? Sembra che la rimozione dei file non sia necessariamente ciò che l'OP vuole. Hanno chiesto "una sovrascrittura di file locali", non la cancellazione.
    2014-03-04 08: 28: 11Z

Avviso, facendo ciò eliminerai definitivamente i tuoi file se hai voci di directory /* nel tuo file gitignore.

Alcune risposte sembrano essere terribili. Terribile nel senso di ciò che è successo a @Lauri seguendo il suggerimento di David Avsajanishvili.

Piuttosto (git > v1.7.6):

 
git stash --include-untracked
git pull

In seguito puoi pulire la cronologia di scorta.

Manualmente, uno per uno:

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

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

Brutalmente, tutto in una volta:

 
$ git stash clear

Ovviamente se vuoi tornare a ciò che hai nascosto:

 
$ git stash list
...
$ git stash apply stash@{5}
    
106
2018-03-07 07: 00: 46Z
  1. No, non la penso così. Stashing sposta semplicemente i file non salvati. Il precedente sposta anche i file (stash) che git non traccia. Questo impedisce ai file che sono stati aggiunti al telecomando, che non sono ancora stati abbattuti sul tuo computer, ma che hai creato (!) - per essere tirati giù. Tutto senza distruggere il lavoro non impegnato. Spero che abbia un senso?
    2012-03-20 23: 54: 34Z
  2. Se non hai 1.7.6, puoi imitare il --include-untracked semplicemente temporaneamente git add -ingendo il tuo intero repository, quindi mettilo immediatamente in memoria.
    2012-05-01 22: 48: 15Z
  3. Sono d'accordo con Hedgehog. Se fai le risposte più popolari qui, probabilmente scoprirai che hai inavvertitamente ucciso un sacco di cose che non volevi davvero perdere.
    2013-01-31 21: 28: 03Z
  4. Ho avuto altri file non tracciati - oltre a quello che l'unione /pull voleva sovrascrivere, quindi questa soluzione ha funzionato al meglio. git stash apply ha riportato tutti i miei file non tracciati con l'eccezione (giustamente) di quelli che l'unione aveva già creato: "Esiste già, nessun checkout". Ha funzionato perfettamente.
    2013-04-25 04: 55: 09Z
  5. Questa è la risposta più pulita e dovrebbe essere accettata. Per salvare un po 'di digitazione puoi usare il modulo breve: git stash -u.
    2017-03-23 ​​08: 30: 32Z

Potresti trovare utile questo comando per eliminare le modifiche locali:

 
git checkout <your-branch> -f

E poi fai una pulizia (rimuove i file non tracciati dall'albero di lavoro):

 
git clean -f

Se vuoi rimuovere le directory non tracciate oltre ai file non tracciati:

 
git clean -fd
    
91
2017-01-14 15: 12: 22Z
  1. Penso che la descrizione dello scenario chiarisca che non vuole davvero buttare via il contenuto. Piuttosto ciò che vuole è smettere di git baulking per sovrascrivere i file. Vedi il mio suggerimento.
    2012-02-11 23: 03: 53Z
  2. Anche se quella risposta potrebbe non corrispondere esattamente alla descrizione, mi ha comunque salvato dalla frustrazione di git twiddling con i ritorni a capo (evento con autocrlf false). Quando git resettato --hard HEAD non ti lascia con "no" file modificati, questi flag "-f" sono abbastanza utili. Grazie mille.
    2013-01-16 10: 28: 58Z

Invece di fondersi con git pull, prova questo:

git fetch --all

seguito da:

git reset --hard origin/master.

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

L'unica cosa che ha funzionato per me è stata:

 
git reset --hard HEAD~5

Questo ti riporterà cinque commit e poi con

 
git pull

L'ho trovato cercando come annullare una fusione Git .

    
57
2017-05-23 10: 31: 37Z
  1. Questo è ciò che alla fine ha funzionato per me poiché ho forzato il mio ramo verso il repository di origine e ho continuato a ottenere conflitti di merge quando provavo a portarlo al mio repository remoto ..
    2014-05-07 05: 16: 17Z
  2. Ciao, in realtà questo è un trucco per un work around ma veramente efficace. Poiché alcuni conflitti possono verificarsi solo in pochi commit, il ripristino di 5 commit garantisce che non vi siano conflitti con il codice remoto.
    2014-11-21 10: 03: 43Z

Il problema con tutte queste soluzioni è che sono tutte troppo complesse o, un problema ancora più grande, è che rimuovono tutti i file non tracciati dal server web, cosa che non vogliamo poiché ci sono sempre file di configurazione necessari che si trovano sul server e non nel repository Git.

Ecco la soluzione più pulita che stiamo utilizzando:

 
# 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
  • Il primo comando recupera i dati più recenti.

  • Il secondo comando controlla se ci sono file che vengono aggiunti al repository ed elimina quei file non tracciati dal repository locale che causerebbero conflitti.

  • Il terzo comando estrae tutti i file che sono stati modificati localmente.

  • Finalmente eseguiamo un pull per aggiornare alla versione più recente, ma questa volta senza conflitti, poiché i file non tracciati che sono nel repository non esistono più e tutti i file modificati localmente sono già gli stessi di il repository.

52
2014-05-23 21: 14: 30Z
  1. Usare "git merge origin /master" come ultima riga (come dici tu nella tua nota) invece di "git pull" sarà più veloce come hai già tirato giù qualsiasi cambiamento dal repository git.
    2013-05-06 06: 21: 24Z
  2. Sì, naturalmente, git merge origin/master sarà più veloce e probabilmente anche più sicuro. Dal momento che se qualcuno ha spinto nuove modifiche durante la rimozione di file di questo script (cosa che probabilmente non succederà, ma è possibile), l'intero pull potrebbe fallire. L'unica ragione per cui ho inserito pull è perché qualcuno potrebbe non lavorare sul ramo master, ma qualche altro ramo e volevo che lo script fosse universale.
    2013-09-01 22: 25: 37Z
  3. Se hai creato localmente file come i file di opzioni, inseriscili in .gitignore.
    2017-11-21 11: 41: 39Z

Ho avuto lo stesso problema. Nessuno mi ha dato questa soluzione, ma ha funzionato per me.

L'ho risolto con:

  1. Elimina tutti i file. Lascia solo la directory .git.
  2. git reset --hard HEAD
  3. git pull
  4. git push

Ora funziona.

    
42
2019-01-18 23: 00: 30Z
  1. Lo stesso qui. A volte funziona solo la soluzione molto difficile, capita spesso che solo il reset e la pulizia non siano sufficienti in qualche modo ...
    2011-12-15 11: 28: 09Z

Prima di tutto, prova in modo standard:

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

Avviso : i comandi sopra riportati possono comportare la perdita di dati /file solo se non li hai impegnati! Se non sei sicuro, crea prima il backup dell'intera cartella del repository.

Quindi tiralo di nuovo.

Se sopra non ti sarà d'aiuto e non ti preoccupi dei tuoi file /directory non tracciati (fai il backup prima solo nel caso), prova i seguenti semplici passaggi:

 
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

Questo rimuoverà tutti i file git (es. .git/ dir, dove hai tutti i commit) e lo tiri di nuovo.


Perché il git reset HEAD --hard potrebbe fallire in alcuni casi?

  1. Regole personalizzate in .gitattributes file

    Avere la regola eol=lf in .gitattributes potrebbe far sì che git modifichi alcune modifiche ai file convertendo le terminazioni di riga CRLF in LF in alcuni file di testo.

    Se questo è il caso, devi impegnare queste modifiche CRLF /LF (rivedendole in git status), o provare: git config core.autcrlf false a ignorarle temporaneamente.

  2. Inabilità del file system

    Quando utilizzi il file system che non supporta gli attributi di autorizzazione. Nell'esempio si hanno due repository, uno su Linux /Mac (ext3/hfs+) e un altro su file system basato su FAT32 /NTFS.

    Come noti, ci sono due diversi tipi di file system, quindi quello che non supporta i permessi Unix non può sostanzialmente ripristinare i permessi dei file sul sistema che non supporta quel tipo di permessi, quindi non importa quanto --hard provi, git rileva sempre alcuni "cambiamenti".

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

Bonus:

Parlando di pull /fetch /merge nelle risposte precedenti, mi piacerebbe condividere un trucco interessante e produttivo,

git pull --rebase

Questo comando sopra è il comando più utile nella mia vita Git che ha risparmiato un sacco di tempo.

Prima di inviare il tuo nuovo commit al server, prova questo comando e sincronizzerà automaticamente le ultime modifiche del server (con un fetch + unisci) e posizionerà il tuo commit nella parte superiore del log Git. Non è necessario preoccuparsi di pull /unione manuale.

Trova i dettagli in Che cosa fa "git pull --rebase"? .

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

Ho avuto un problema simile. Ho dovuto fare questo:

 
git reset --hard HEAD
git clean -f
git pull
    
27
2011-11-06 16: 35: 34Z
  1. usa git clean con cautela
    2012-03-30 16: 39: 22Z

Sulla base delle mie esperienze simili, la soluzione offerta da Strahinja Kustudic sopra è di gran lunga la migliore. Come altri hanno sottolineato, la semplice reimpostazione completa rimuoverà tutti i file non tracciati che potrebbero includere molte cose che non vorresti rimuovere, come i file di configurazione. Ciò che è più sicuro, è quello di rimuovere solo i file che stanno per essere aggiunti e, per questo, è probabile che si desideri anche eseguire il checkout di tutti i file modificati localmente che stanno per essere aggiornati.

Tenendo presente, ho aggiornato lo script di Kustudic per fare proprio questo. Ho anche corretto un refuso (mancante 'nell'originale).

 
#/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. Usare "git merge origin /master" come ultima riga (come dici tu nella tua nota) invece di "git pull" sarà più veloce come hai già tirato giù qualsiasi cambiamento dal repository git.
    2013-05-06 06: 20: 47Z
  2. Il checkout dei file modificati è necessario, quindi funziona al 100% delle volte. Ho aggiornato il mio script con quello molto tempo fa, ma ho dimenticato di aggiornare anche qui. Lo uso anche un po 'diversamente da te. Eseguo il checkout dei file che hanno qualsiasi tipo di modifica, non solo M, quindi funziona sempre.
    2013-09-01 22: 48: 40Z

Ho riassunto altre risposte. Puoi eseguire git pull senza errori:

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

Avviso : questo script è molto potente, quindi potresti perdere le modifiche.

    
27
2017-01-14 15: 42: 28Z
  1. Questo sovrascriverà i file modificati (file precedentemente archiviati) e rimuoverà i file non tracciati (file che non sono mai stati registrati). Esattamente quello che stavo cercando, grazie!
    2016-03-03 16: 01: 46Z
  2. Sospetto che la terza riga git reset --hard HEAD possa essere ridondante; la mia pagina man locale (2.6.3) dice che reset nella seconda riga git reset --hard origin/master "per default è HEAD in tutte le forme."
    2016-04-19 15: 40: 52Z
  3. @ arichards Penso che il tuo sospetto sia giusto ma se la seconda linea non funzionerà (per qualsiasi motivo) la terza riga funziona bene per resettare. Questa soluzione non ha bisogno di essere ottimizzata. Ho appena riassunto altre risposte. È tutto. Grazie per il tuo commento. :)
    2016-04-20 02: 12: 45Z

Credo che ci siano due possibili cause di conflitto, che devono essere risolte separatamente, e per quanto posso dire, nessuna delle risposte di cui sopra si occupa di entrambi:

  • I file locali che non sono tracciati devono essere eliminati, manualmente (più sicuro) o come suggerito in altre risposte, per git clean -f -d

  • I commit locali che non sono sul ramo remoto devono essere eliminati. IMO il modo più semplice per ottenerlo è: git reset --hard origin/master (sostituisci "master" con qualsiasi ramo su cui stai lavorando ed esegui prima un git fetch origin)

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

Sembra che la maggior parte delle risposte qui siano focalizzate sul ramo master; tuttavia, ci sono momenti in cui sto lavorando sullo stesso ramo di funzione in due luoghi diversi e voglio che un rebase in uno si rifletta nell'altro senza un sacco di salti mortali.

Basato su una combinazione di risposta di RNA e risposta di torek a una domanda simile , ho trovato questo che funziona splendidamente:

 
git fetch
git reset --hard @{u}

Esegui questo da un ramo e resetterà solo il tuo ramo locale alla versione upstream.

Questo può anche essere inserito in un alias git (git forcepull):

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

Oppure, nel tuo file .gitconfig:

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

Enjoy!

    
20
2017-05-23 12: 18: 32Z
  1. Questa risposta è anche carina perché funziona indipendentemente dal ramo in cui ti trovi!
    2018-09-11 20: 14: 56Z

Un modo più semplice sarebbe:

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

Questo sovrascriverà il tuo file locale con il file su git

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

Ho avuto lo stesso problema e per qualche ragione, anche un git clean -f -d non lo farebbe. Ecco perché: per qualche ragione, se il tuo file è ignorato da Git (tramite una voce .gitignore, presumo), si preoccupa ancora di sovrascrivere questo con un pull , ma un pulito non lo rimuoverà, a meno che tu non aggiunga -x.

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

L'ho appena risolto io stesso:

 
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

dove l'ultimo comando fornisce un elenco delle modifiche locali. Continua a modificare il ramo "tmp" finché non è accettabile e quindi unisci nuovamente a master con:

 
git checkout master && git merge tmp

Per la prossima volta, probabilmente puoi gestirlo in un modo più pulito cercando "git stash branch" anche se lo stash rischia di causare problemi nei primi tentativi, quindi fai il primo esperimento su un progetto non critico. .

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

Ho una strana situazione che non funziona né su git clean né su git reset. Devo rimuovere il file in conflitto da git index utilizzando il seguente script su ogni file non tracciato:

 
git rm [file]

Allora sono in grado di tirare bene.

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

Lo sodi un metodo molto più semplice e meno doloroso:

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

Questo è tutto!

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

Questi quattro comandi funzionano per me.

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

Per controllare /tirare dopo aver eseguito questi comandi

 
git pull origin master

Ho provato molto, ma alla fine ho avuto successo con questi comandi.

    
13
2014-03-20 04: 24: 02Z
  1. "git branch -D master" elimina il ramo. quindi fai attenzione. Preferisco usare "git checkout origin /master -b < nuovo nome di ramo >" che creano un nuovo ramo con un nuovo nome e hai bisogno di 3,4 righe. Consigliamo anche di usare "git clean -f" pure.
    2014-04-05 11: 49: 57Z

Nonostante la domanda originale, le risposte migliori possono causare problemi a persone che hanno un problema simile, ma non vogliono perdere i loro file locali. Ad esempio, vedi i commenti di Al-Punk e crizCraig.

La seguente versione esegue il commit delle modifiche locali su un ramo temporaneo (tmp), controlla il ramo originale (che presumo sia master) e unisce gli aggiornamenti. Puoi farlo con stash, ma ho scoperto che di solito è più semplice utilizzare semplicemente l'approccio branch /merge.

 
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

dove supponiamo che il altro repository sia origin master.

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

Basta fare

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

Così eviti tutti gli effetti collaterali indesiderati, come l'eliminazione di file o directory che desideri conservare, ecc.

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

Ripristina l'indice e la testina su origin/master, ma non resetta l'albero di lavoro:

 
git reset origin/master
    
11
2013-02-15 13: 41: 43Z
  1. Personalmente ho trovato che questo è molto utile. Quindi mantiene il tuo albero di lavoro in modo da poterlo verificare di nuovo. Per il mio problema, ho avuto gli stessi file cancellati come aggiunti, quindi è stato bloccato. Strano, lo so.
    2014-01-04 21: 03: 59Z

Ho letto tutte le risposte ma stavo cercando un singolo comando per farlo. Ecco cosa ho fatto. Aggiunto un alias git a .gitconfig

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

Esegui il tuo comando come

 
git fp origin master

equivalente a

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

Requisiti:

  1. Tieni traccia dei cambiamenti locali così nessuno li perde mai.
  2. Rendi il repository locale corrispondente al repository di origine remoto.

Soluzione:

  1. Conserva le modifiche locali.
  2. Recupera con un pulito di file e directory che ignorano .gitignore e hard reset a origine .

     
    git stash --include-untracked
    git fetch --all
    git clean -fdx
    git reset --hard origin/master
    
9
2017-01-14 15: 44: 53Z
fonte posta Qui