Git non può scollegare il file durante pull - come posso uscire dallo stato incoerente del repository?

Question

Mentre si esegue "git pull", git ha interrotto l'operazione poiché non è stato possibile scollegare un file che si desidera sovrascrivere, perché ho dimenticato di chiudere un'applicazione bloccata su questi file.

Quando chiudo l'applicazione e provare a rieseguire "git pull" e il seguente messaggio di errore:

"Error: Your local changes to the following files would be overwritten by merge: ..." 

e

"Error: The following untracked working tree files would be overwritten by merge: ..." 

Chiaramente, git appena abortito il tiro senza fare un rotolo -back e ora pensa che i cambiamenti che sono stati appena estratti sono i miei cambiamenti locali.

Come uscire da questo stato? Stiamo parlando di molti file, e prima di fare un "git revert" dovrei controllare manualmente per ogni file se ci fossero alcune modifiche locali da parte mia.

Nota: stiamo utilizzando git in una configurazione tipo client-server, in cui gli sviluppatori distribuiti "pull" e "push & commit" frequentemente in un repository di bitbucket centrale.

Answer 1

Poiché nessuno dei metodi sopra descritti ha funzionato per me, ho utilizzato una procedura che non è completamente automatica, ma riduce lo sforzo su alcuni file selezionati manualmente (nel mio caso 2 anziché 50).

Prima Stash tutti i file (inclusi i non tracciata e ignorato) utilizzando

git stash save --all    

quindi ripetere il tiro, che in precedenza non sono riusciti, utilizzando

git pull       

Ora cassa dalla scorta per sovrascrivere semplicemente tutti i file, che sono stati modificati durante il primo pull (nessun tentativo di unione):

git checkout stash -- .   

Ora un problema è rimasto: le modifiche apportate sul server tra il pull fallito e il secondo pull ora vengono sovrascritte. Ma quelli dovrebbero essere solo alcuni file (se il tempo tra i due "pull" era breve), e molto più facile da identificare nella lista delle modifiche di lavoro che hai fatto tu stesso. Semplicemente "ripristinali" (ho usato la finestra di dialogo di commit GIT Tortoise) prima di eseguire il commit finale.

git commit 
git stash drop 

Answer 2

Prova

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

o se siete su qualche altro ramo

git reset --hard origin/your_branch 

Spiegazione:

git fetch download l'ultima da remoto senza cercare di unire o rebase nulla.

Quindi il git reset reimposta il ramo master su ciò che è stato appena recuperato. L'opzione --hard cambia tutti i file nel vostro albero di lavoro per abbinare i file in origin/master

Vale la pena notare che è possibile mantenere attuali commit locali con la creazione di 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 

Answer 3

git reset --hard 

resetterà tutti monitorati i file al loro stato commesso.

git clean -df 

pulisce tutti i file non tracciati non monitorati rimanenti.

Quindi è possibile ripetere il pull. L'unione semplice lo farà, hai già eseguito il recupero.

---

Sono quasi sicuro che il comportamento sia dovuto a una differenza nel modo in cui Windows vuole che i file funzionino. In Unix-land, una volta aperto il file, viene rilasciata la voce della directory. L'errore che stai vedendo semplicemente non accade sul sistema Unix; il file aperto diventerebbe temporaneo, esistente fino a quando rimarrà aperto a qualche processo. Ci sono anche aspetti negativi nel modo Unix, si vede un aspetto negativo del modo in cui Windows. La soluzione è abbastanza facile, ripristinata e pulita sono praticamente la tua squadra di pulizia del cantiere. È un lavoro onorevole, li conosco, loro conoscono le loro cose.