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

Lo scenario è il seguente:

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

Questo è l'errore che sto ricevendo:

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

Come posso 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.

Importante: in caso di modifiche locali, queste andranno perse. Con o senza --hardopzione, tutti gli commit locali che non sono stati inviati verranno persi. ^[*]

Se si dispone di file non monitorati da Git (ad es. Contenuto utente caricato), 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 in ​​un'altra filiale:

git reset --hard origin/<branch_name>

Spiegazione:

git fetch scarica le ultime dal telecomando senza tentare di unire o rifare nulla.

Quindi git resetreimposta il ramo principale su ciò che hai appena recuperato. L' --hardopzione modifica tutti i file dell'albero di lavoro in modo che corrispondano ai file inorigin/master

Mantieni gli impegni locali correnti

^[*] : Vale la pena notare che è possibile mantenere gli attuali commit locali creando una succursale masterprima di ripristinare:

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

Dopodiché, tutti i vecchi commit verranno mantenuti new-branch-to-save-current-commits.

Modifiche non confermate

Le modifiche non confermate, tuttavia (anche in fasi), andranno perse. Assicurati di riporre e impegnare tutto ciò di cui hai bisogno. Per questo è possibile eseguire quanto segue:

git stash

E quindi applicare nuovamente queste modifiche non impegnate:

git stash pop

Prova questo:

git reset --hard HEAD
git pull

Dovrebbe fare quello che vuoi.

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

A volte clean -fnon aiuta. Se hai DIRECTORIES non tracciati, l'opzione -d aveva bisogno anche di:

# WARNING: this can't be undone!

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

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

Valuta di usare prima il flag -n( --dry-run). Questo ti mostrerà cosa verrà eliminato senza cancellare 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
...

Come il riccio, penso che le risposte siano terribili. Ma sebbene la risposta di Hedgehog potrebbe essere migliore, non penso che sia elegante come potrebbe essere. Il modo in cui ho scoperto di farlo è utilizzando "recupera" e "unisci" con una strategia definita. Il che dovrebbe far sì che le modifiche locali vengano mantenute purché non siano uno dei file con cui si sta tentando di forzare una sovrascrittura.

Prima fai un commit delle tue modifiche

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

Quindi recuperare le modifiche e sovrascrivere in caso di conflitto

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

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

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 hai bisogno di recuperare tutti i telecomandi e le filiali se hai intenzione di ripristinare il ramo di origine / master giusto?

Sembra che il modo migliore sia prima fare:

git clean

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

Attenzione, facendo questo eliminerai definitivamente i tuoi file se hai qualche directory / * voci nel tuo file gitignore.

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

Piuttosto (git> v1.7.6):

git stash --include-untracked
git pull

Successivamente è possibile ripulire 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}

Questo comando potrebbe essere utile per eliminare le modifiche locali:

git checkout <your-branch> -f

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

git clean -f

Se si desidera rimuovere le directory non tracciate oltre ai file non tracciati:

git clean -fd

Invece di fonderti con git pull, prova questo:

git fetch --all

seguito da:

git reset --hard origin/master.

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

git reset --hard HEAD~5

Questo ti riporterà cinque commit e poi con

git pull

Ho scoperto che cercando come annullare un'unione Git .

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 su il server e non nel repository Git.

Ecco la soluzione più pulita che stiamo usando:

# 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 dal repository locale quei file non tracciati che potrebbero causare conflitti.

• Il terzo comando esegue il checkout di tutti i file che sono stati modificati localmente.

• Infine, facciamo un tentativo per aggiornare alla versione più recente, ma questa volta senza conflitti, poiché i file non tracciati presenti nel repository non esistono più e tutti i file modificati localmente sono già gli stessi del repository.

Prima di tutto, prova nel modo standard:

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

^{Avvertenza : i comandi precedenti possono comportare la perdita di dati / file solo se non li hai impegnati! Se non si è sicuri, eseguire prima il backup dell'intera cartella del repository.}

Quindi tiralo di nuovo.

Se sopra non aiuta e non ti importa dei file / directory non tracciati (esegui prima il backup per ogni evenienza), 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 (excempt .git/dir, dove hai tutti i commit) e lo tirerà di nuovo.

Perché git reset HEAD --hardin alcuni casi potrebbe fallire?

1. Regole personalizzate in .gitattributes file

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

   In tal caso, devi eseguire il commit di queste modifiche CRLF / LF (rivedendole git status) o provare: git config core.autcrlf falseignorarle temporaneamente.

2. Incompatibilità del file system

   Quando si utilizza un file system che non supporta gli attributi di autorizzazione. Ad esempio, hai due repository, uno su Linux / Mac ( ext3/ hfs+) e un altro sul file system basato su FAT32 / NTFS.

   Come noterai, ci sono due diversi tipi di file system, quindi quello che non supporta le autorizzazioni Unix non può sostanzialmente ripristinare le autorizzazioni dei file sul sistema che non supporta quel tipo di autorizzazioni, quindi non importa come --hardci provi, git rileva sempre alcuni "cambiamenti".

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 .gitdirectory.
2. git reset --hard HEAD
3. git pull
4. git push

Ora funziona.

Bonus:

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

git pull --rebase

Questo comando sopra è il comando più utile nella mia vita di Git che mi ha fatto risparmiare molto tempo.

Prima di inviare il tuo nuovo commit al server, prova questo comando e sincronizzerà automaticamente le ultime modifiche del server (con un fetch + merge) e posizionerà il tuo commit in alto nel registro Git. Non è necessario preoccuparsi del pull / merge manuale.

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

Ho avuto un problema simile. Ho dovuto fare questo:

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

Ho riassunto altre risposte. Puoi eseguire git pullsenza errori:

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

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

Sulla base delle mie esperienze simili, la soluzione offerta da Strahinja Kustudic sopra è di gran lunga la migliore. Come altri hanno sottolineato, semplicemente facendo un hard reset si rimuoveranno tutti i file non tracciati che potrebbero includere molte cose che non si desidera rimuovere, come i file di configurazione. Ciò che è più sicuro, è rimuovere solo i file che stanno per essere aggiunti e, del resto, è probabile che tu voglia controllare anche tutti i file modificati localmente che stanno per essere aggiornati.

Ciò in mente, ho aggiornato la sceneggiatura 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

Credo che ci siano due possibili cause di conflitto, che devono essere risolte separatamente, e per quanto ne so nessuna delle risposte di cui sopra riguarda entrambe:

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

• Anche i commit locali che non si trovano nella filiale remota devono essere eliminati. IMO il modo più semplice per raggiungere questo obiettivo è: git reset --hard origin/master(sostituisci "master" con qualsiasi ramo su cui stai lavorando ed esegui un git fetch originprimo)

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

Sembra che la maggior parte delle risposte qui siano focalizzate sul masterramo; tuttavia, ci sono momenti in cui sto lavorando allo stesso ramo di funzionalità in due luoghi diversi e voglio che un rebase in uno si rifletta nell'altro senza saltare molti cerchi.

Sulla base di una combinazione della risposta di RNA e della risposta di Torek a una domanda simile , ho trovato questo che funziona magnificamente:

git fetch
git reset --hard @{u}

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

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

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

Oppure, nel tuo .gitconfigfile:

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

Godere!

Ho avuto lo stesso problema e per qualche motivo, anche a git clean -f -dnon lo farei. Ecco perché: per qualche motivo, se il tuo file viene ignorato da Git (tramite una voce .gitignore, suppongo), si preoccupa ancora di sovrascriverlo con un pull successivo , ma un clean non lo rimuoverà, a meno che non lo aggiungi -x.

Conosco 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!

L'ho risolto da solo:

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" fino a quando non è accettabile, quindi ricollegalo al master con:

git checkout master && git merge tmp

Per la prossima volta, puoi probabilmente gestirlo in modo più pulito guardando "git stash branch" anche se è probabile che stash possa causare problemi nei primi tentativi, quindi fai prima un esperimento su un progetto non critico ...

Ho una situazione strana che né git cleano git resetopere. Devo rimuovere il file in conflitto git indexutilizzando lo script seguente su ogni file non tracciato:

git rm [file]

Quindi sono in grado di tirare bene.

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

Nonostante la domanda originale, le risposte migliori possono causare problemi alle 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 versione seguente memorizza le modifiche locali in un ramo temporaneo ( tmp), verifica il ramo originale (che presumo sia master) e unisce gli aggiornamenti. Potresti farlo con stash, ma ho scoperto che di solito è più semplice usare 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 si assume l' altro repository è origin master.

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

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

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

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

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

git reset origin/master

Requisiti:

1. Tieni traccia delle modifiche locali in modo che nessuno qui le perda mai.
2. Rendi il repository locale corrispondente al repository di origine remoto.

Soluzione:

1. Riporta le modifiche locali.

2. Fetch con un pulito di file e directory ignorando .gitignore e hard reset di origine .

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