recuperare dall'origine con rami remoti eliminati?


Risposte:


812

Devi fare quanto segue

git fetch -p

Ciò aggiornerà il database locale delle filiali remote.


1
Grazie mille. Ho eliminato manualmente quei rami prima.
Maksim Dmitriev

4
Per qualche ragione, il tuo comando non ha funzionato, ma questo ha funzionato per un ramo remoto inesistente nel mio originfork: git fetch -p origin quando ho fatto git branch -r il ramo remoto inesistente non è più apparso.
oldfartdeveloper

11
Per completezza: devono essere uguali git remote prune origine simili a quelli git pull --prunemenzionati rispettivamente su stackoverflow.com/a/6127884/94687 e stackoverflow.com/a/17983126/94687 .
imz - Ivan Zakharyaschev,

6
ragazzi quando lo faccio dice [deleted] (none) -> origin/ < branch name >e il ramo è ancora mostrato sul repository locale qualche idea del perché?
Buddhi741,

4
Ricevo un messaggio che dice che i miei rami sono stati eliminati, ma l'esecuzione git branchmostra ancora i rami che presumibilmente sono stati eliminati.
sdfsdf,

91

Da http://www.gitguys.com/topics/adding-and-removing-remote-branches/

Dopo che qualcuno ha eliminato un ramo da un repository remoto, git non cancellerà automaticamente i rami del repository locale quando un utente esegue un pull o un recupero git. Tuttavia, se l'utente desidera rimuovere tutti i rami di tracciamento dal proprio repository locale che sono stati eliminati in un repository remoto, può digitare:

git origine della prugna remota

Come nota, il parametro -p in git fetch -prealtà significa "potare".
In entrambi i casi, i rami remoti inesistenti verranno eliminati dal repository locale.


Mi piace dal momento che non recupera nulla di nuovo.
Marek R,

30

Devi fare quanto segue

git fetch -p

per sincronizzare l'elenco delle filiali. Il manuale di git dice

-p, --prune
Dopo il recupero, rimuovere eventuali riferimenti di tracciamento remoto che non esistono più sul telecomando. I tag non sono soggetti a potatura se vengono recuperati solo a causa del tag automatico che segue automaticamente o a causa di --tagsun'opzione. Tuttavia, se i tag vengono recuperati a causa di un refspec esplicito (nella riga di comando o nella configurazione remota, ad esempio se il telecomando è stato clonato con l' --mirroropzione), sono anche soggetti a potatura.

Personalmente mi piace usare git fetch origin -p --progressperché mostra un indicatore di progresso.


11

Questo ha funzionato per me.

git remote update --prune

6

Per quanto riguarda git fetch -p, il suo comportamento è cambiato in Git 1.9 e solo Git 2.9.x / 2.10 lo riflette.

Vedi commit 9e70233 (13 giu 2016) di Jeff King ( peff) .
(Unito da Junio ​​C Hamano - gitster- in commit 1c22105 , 06 lug 2016)

fetch: documenta che la potatura avviene prima del recupero

Questo è stato modificato in 10a6cc8 ( fetch --prune: esegui la prugna prima del recupero, 2014-01-02), ma sembra che nessuno in quella discussione abbia realizzato che stavamo pubblicizzando il "dopo" esplicitamente.

Quindi la documentazione ora afferma:

Prima di recuperare, rimuovere eventuali riferimenti di tracciamento remoto che non esistono più sul telecomando

Questo perchè:

Quando abbiamo un ramo di tracciamento remoto chiamato " frotz/nitfol" da un precedente recupero e ora l'upstream ha un ramo chiamato " frotz", il recupero non riuscirebbe a rimuovere " frotz/nitfol" con un " git fetch --prune" dall'upstream. git informerebbe l'utente di usare " git remote prune" per risolvere il problema.

Cambia il modo in cui " fetch --prune" funziona spostando l'operazione di potatura prima dell'operazione di recupero. In questo modo, invece di avvisare l'utente di un conflitto, lo risolve automaticamente.

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.