Quando eu faço git fetch origine a origem tem um ramo excluído, ele não parece atualizá-lo no meu repositório. Quando eu faço git branch -risso ainda mostra origin/DELETED_BRANCH.
Como posso consertar isso?
Respostas:
Você precisa fazer o seguinte
git fetch -p
Isso atualizará o banco de dados local de ramificações remotas.
originfork: git fetch -p origin Quando fiz isso, git branch -r a ramificação remota inexistente não apareceu mais.
git remote prune origine semelhante ao git pull --prunemencionado em stackoverflow.com/a/6127884/94687 e stackoverflow.com/a/17983126/94687, respectivamente.
[deleted] (none) -> origin/ < branch name >e o ramo ainda é mostrado no repositório local alguma idéia por quê?
git branchainda mostra os ramos que supostamente foram excluídos.
Em http://www.gitguys.com/topics/adding-and-removing-remote-branches/
Depois que alguém exclui uma ramificação de um repositório remoto, o git não exclui automaticamente as ramificações do repositório local quando um usuário faz um pull ou busca do git. No entanto, se o usuário desejar remover todos os ramos de rastreamento do repositório local que foram excluídos em um repositório remoto, eles poderão digitar:
origem de remoção remota git
Como uma observação, o parâmetro -p de git fetch -prealmente significa "remoção".
De qualquer maneira que você escolher, as ramificações remotas inexistentes serão excluídas do seu repositório local.
Você precisa fazer o seguinte
git fetch -p
para sincronizar sua lista de filiais. O manual git diz
-p,--prune
Após buscar, remova as referências de rastreamento remoto que não existem mais no controle remoto. As tags não estão sujeitas a remoção se forem buscadas apenas por causa do acompanhamento automático da tag padrão ou devido a uma--tagsopção. No entanto, se as tags forem buscadas devido a um refspec explícito (na linha de comandos ou na configuração remota, por exemplo, se o controle remoto foi clonado com a--mirroropção), elas também estarão sujeitas a remoção.
Eu pessoalmente gosto de usar git fetch origin -p --progressporque mostra um indicador de progresso.
Em relação a git fetch -p, seu comportamento mudou no Git 1.9, e apenas o Git 2.9.x / 2.10 reflete isso.
Veja commit 9e70233 (13 de junho de 2016) por Jeff King ( peff) .
(Mesclado por Junio C Hamano - gitster- na confirmação 1c22105 , 06 de julho de 2016)
fetch: documento que a poda acontece antes da buscaIsso foi alterado em 10a6cc8 (
fetch --prune: Executar remoção antes da busca, 02-01-2014), mas parece que ninguém nessa discussão percebeu que estávamos anunciando o "depois" explicitamente.
Portanto, a documentação agora afirma:
Antes de buscar, remova as referências de rastreamento remoto que não existem mais no controle remoto
Isso é porque:
Quando temos um ramo de rastreamento remoto chamado "
frotz/nitfol" a partir de uma busca anterior, e o upstream agora tem um ramo chamado "frotz", a busca falha ao remover "frotz/nitfol" com um "git fetch --prune" do upstream. O git informa o usuário a usar "git remote prune" para corrigir o problema.Mude a maneira como "
fetch --prune" funciona movendo a operação de remoção antes da operação de busca. Dessa forma, em vez de avisar o usuário sobre um conflito, ele o corrige automaticamente.