Quando lo faccio git fetch origine l'origine ha un ramo eliminato, non sembra aggiornarlo nel mio repository. Quando lo faccio git branch -rmostra ancoraorigin/DELETED_BRANCH .
Come posso risolvere questo problema?
Risposte:
Devi fare quanto segue
git fetch -p
Ciò aggiornerà il database locale delle filiali remote.
originfork: git fetch -p origin quando ho fatto git branch -r il ramo remoto inesistente non è più apparso.
git remote prune origine simili a quelli git pull --prunemenzionati rispettivamente su stackoverflow.com/a/6127884/94687 e stackoverflow.com/a/17983126/94687 .
[deleted] (none) -> origin/ < branch name >e il ramo è ancora mostrato sul repository locale qualche idea del perché?
git branchmostra ancora i rami che presumibilmente sono stati eliminati.
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.
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.
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 recuperoQuesto è 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.