Git Pull non è possibile, file non uniti


90

Ho letto tutte le domande simili su questo; sembra che nessuno dei seguenti abbia funzionato:

Delete offending files
git reset --hard HEAD
git stash
git pull

Quasi ogni combinazione, l'archiviazione delle modifiche e l'estrazione dal repository, si traduce in file non unificabili. Vorrei scartare tutte le modifiche locali e usare solo il telecomando, ma non posso clonare di nuovo (larghezza di banda e limitazioni dell'uso di Internet con lo sviluppatore che cerca di farlo). Come faccio a fare questo?

Appena provato:

git stash
git pull

Inoltre non ha funzionato.

Ulteriori informazioni

C'è un commit locale e anche l'upstream ha un commit. Ho quindi provato git pull --rebasema non funziona ancora correttamente ... Questo mi dà errori - "uscita a causa di un conflitto irrisolto". Se lo faccio git stash, git reset --hard HEAD, git pull --rebase, ricevo l'errore "pull non è possibile, modifiche non unite ..."

Risposte:


202

Supponi che il telecomando sia origine il ramo lo sia master, e che tu abbia già masterestratto, potresti provare quanto segue:

git fetch origin
git reset --hard origin/master

Questo fondamentalmente prende solo il ramo corrente e lo punta al HEADramo remoto.

ATTENZIONE : come indicato nei commenti, questo eliminerà le modifiche locali e sovrascriverà tutto ciò che si trova nell'origine .

Oppure puoi usare i comandi idraulici per fare essenzialmente lo stesso:

git fetch <remote>
git update-ref refs/heads/<branch> $(git rev-parse <remote>/<branch>)
git reset --hard

EDIT: vorrei spiegare brevemente perché funziona.

La .gitcartella può contenere i commit per qualsiasi numero di repository. Poiché l'hash del commit è in realtà un metodo di verifica per il contenuto del commit e non solo un valore generato casualmente, viene utilizzato per abbinare i set di commit tra i repository.

Un ramo è solo un puntatore con nome a un dato hash. Ecco un set di esempio:

$ find .git/refs -type f
.git/refs/tags/v3.8
.git/refs/heads/master
.git/refs/remotes/origin/HEAD
.git/refs/remotes/origin/master

Ciascuno di questi file contiene un hash che punta a un commit:

$ cat .git/refs/remotes/origin/master
d895cb1af15c04c522a25c79cc429076987c089b

Questi sono tutti per il meccanismo di archiviazione di git interno e funzionano indipendentemente dalla directory di lavoro . In questo modo:

git reset --hard origin/master

git punterà il ramo corrente allo stesso valore hash a cui punta origin / master. Quindi cambia con forza la directory di lavoro in modo che corrisponda alla struttura / contenuto del file in quell'hash.

Per vederlo all'opera, vai avanti e prova quanto segue:

git checkout -b test-branch
# see current commit and diff by the following
git show HEAD
# now point to another location
git reset --hard <remote>/<branch>
# see the changes again
git show HEAD

2
Dalla recente modifica approvata aggiungendo il massiccio avviso all'inizio, proprio per sottolineare che è già menzionato: "Quindi [git] cambia con forza la directory di lavoro in modo che corrisponda alla struttura / contenuto del file in quell'hash." Ma immagino che non fosse abbastanza esplicito.
Trevor Norris


6

Risolto, utilizzando il seguente set di comandi:

git reset --hard
git pull --rebase
git rebase --skip
git pull

Il trucco sta nel rebase delle modifiche ... Abbiamo avuto qualche problema nel rebase di un commit banale, quindi lo abbiamo semplicemente saltato usando git rebase --skip (dopo aver copiato i file).


3

Se ti capita di riscontrare questo problema dopo aver eseguito un git fetche git non ti consente di eseguire a git pullcausa di un conflitto di unione ( entrambi i file modificati / non uniti e per renderti più frustrato, non ti mostrerà alcun marcatore di conflitto nel file poiché non è ancora unito). Se non desideri perdere il tuo lavoro, puoi fare quanto segue.

mettere in scena il file.

$ git add filename

quindi riponi le modifiche locali.

$ git stash

tirare e aggiornare la directory di lavoro

$ git pull

ripristinare il file modificato locale (git si unirà automaticamente se possibile, altrimenti lo risolverà)

$ git stash pop

Spero che possa aiutare.


2

C'è una soluzione anche se non vuoi rimuovere le modifiche locali. Basta correggere i file non uniti (da git addo git remove). Allora fallo git pull.


1

Supponendo che tu voglia buttare via tutte le modifiche che hai, controlla prima l'output di git status. Per qualsiasi file che dice "non unito" accanto ad esso, esegui git add <unmerged file>. Quindi prosegui con git reset --hard. Ciò eliminerà qualsiasi modifica locale ad eccezione dei file non tracciati.


Oh giusto. Potrebbe non dire "non fusa". Potrebbe anche dire "entrambi modificati" o forse una o due altre cose. Qual è l'output di git status?
Ryan Stewart,

Dopo aver pubblicato questo, sto dicendo al membro del team di provare git rebase --aborte git pull --rebasesecondo il suggerimento di git
Christian Stewart,

1

Ho risolto con git rimuovere localmente il file non unito.

$ git rm <the unmerged file name>
$ git reset --hard
$ git pull --rebase
$ git rebase --skip
$ git pull
Already up-to-date.

Quando invio git commit in seguito:

$ git commit . -m "my send commit"
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

0

La risposta di Ryan Stewart era quasi arrivata. Nel caso in cui in realtà non desideri eliminare le modifiche locali, c'è un flusso di lavoro che puoi utilizzare per unire:

  • Corri git status. Ti darà un elenco di file non uniti.
  • Uniscili (a mano, ecc.)
  • Correre git commit

Git eseguirà solo il commit delle unioni in un nuovo commit. (Nel mio caso, avevo file aggiunti aggiuntivi su disco, che non erano raggruppati in quel commit.)

Git quindi considera l'unione riuscita e ti consente di andare avanti.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.