Git prune

A saída do git log exibe os dois commits e as mensagens de commit correspondentes sobre as edições feitas no hello.txt. O próximo passo é tornar um dos commits inacessível, o que vai ser feito com o comando git reset. A gente redefiniu o estado do repositório para o primeiro commit, o commit "hello.txt" adicionado.

Se agora a gente examinar o estado do repositório com o git log, vai ver que tem apenas um commit.

O repositório de demonstração agora está em um estado que contém um commit desanexado. O segundo commit que fizemos com a mensagem "outra linha adicionada ao hello.txt" não é mais exibida na saída do git log e agora está desanexado. Pode parecer que perdemos ou excluímos o commit, mas o Git é muito rigoroso quanto a não excluir o histórico. Podemos confirmar que ele ainda está disponível, mas desanexado, usando o git checkout para fazer uma visita direta:

Quando consultamos o commit desanexado, o Git é atencioso o suficiente para nos dar uma mensagem detalhada explicando que estamos em um estado desanexado. Se examinarmos o log aqui, podemos ver que o commit "outra linha adicionada ao hello.txt" agora está de volta na saída do log! Agora que sabemos que o repositório está em um bom estado de simulação com um commit desanexado, podemos praticar o uso do git prune. Primeiro, vamos retornar ao branch main usando git checkout.

Ao retornar ao principal via git checkout, o Git é atencioso o suficiente mais uma vez para nos informar que estamos deixando um commit desanexado para trás. Agora é hora de remover o commit desanexado! Em seguida, vamos executar o git prune, mas devemos ter certeza de passar algumas opções para ele. --dry-run e --verbose vão exibir a saída indicando o que está definido para ser removido, mas não vai remover as entradas de verdade.

É provável que esse comando retorne uma saída vazia. A saída vazia implica que o prune não vai excluir nada. Mas por quê? Bem, o commit provavelmente não está totalmente desanexado. Em algum lugar, o Git ainda mantém uma referência a ele. Este é um excelente exemplo de por que o git prune não deve ser usado de forma independente fora do git gc. Esse também é um bom exemplo de como é difícil perder os dados por completo com o Git.

O mais provável é que o Git esteja armazenando uma referência ao nosso commit desanexado no reflog. A gente pode investigar executando git reflog. Você deve ver alguma saída descrevendo a sequência de ações que a gente tomou para chegar aqui. Para mais informações sobre o git reflog, visite a página git reflog. Além de preservar o histórico no reflog, o Git tem datas de expiração internas de quando vai remover os commits desanexados. Repetindo, essas são todas as informações de implementação que o git gc manipula e o git prune não deve ser usado de forma independente.

Para concluir nossa demonstração de simulação do git prune, precisamos limpar o reflog.

O comando acima vai forçar a expiração de todas as entradas para o reflog que são mais antigas do que agora. Este é um comando brutal e perigoso que você nunca deveria ter que usar sendo um usuário casual do Git. Estamos executando esse comando para demonstrar um git prune bem-sucedido. Com o reflog totalmente apagado, agora podemos executar o git prune.

Esse comando deve gerar uma lista de referências de objetos Git SHA que se parece com a de cima.

O git prune tem uma pequena lista de opções que abordamos na seção de visão geral.

Não execute o prune. Apenas mostre uma saída do que ele vai fazer

Exibe a saída de todos os objetos e ações tomadas pelo prune

Exibe a saída que indica o progresso do prune

Forçar a expiração de objetos que já passaram do

Especificar um ＜head＞ vai preservar todas as opções dessa ref de cabeçalho

git remote prune e git fetch --prune fazem a mesma coisa: excluem as referências para branches que não existem no remoto. Essa ação é bastante desejável ao trabalhar em um fluxo de trabalho de equipe no qual os branches remotos são excluídos após o merge para o main. O segundo comando, git fetch --prune, vai conectar ao remoto e buscar o estado remoto mais recente antes da remoção. É essencialmente uma combinação de comandos:

O comando genérico git prune é totalmente diferente. Conforme discutido na seção de visão geral, o git prune vai excluir os commits desanexados no local.

O git fetch --prune é o melhor utilitário para limpar branches desatualizados. Ele vai se conectar a um repositório remoto compartilhado e vai buscar todas as referências de branches remotos. Em seguida, ele vai excluir as referências remotas que não estão mais em uso no repositório remoto.

Não, o git remote prune origin vai excluir apenas as refs para branches remotos que não existem mais. O Git armazena as referências locais e remotas. Um repositório vai ter coleções de referência local/origin e remote/origin. git remote prune origin só vai remover as refs em remote/origin. Assim, o trabalho local fica com segurança em local/origin.

O comando git prune deve ser invocado como um comando filho para git gc. É muito improvável que você precise invocar o git prune no dia a dia da engenharia de software. Outros comandos são necessários para entender os efeitos do git prune. Alguns comandos usados neste artigo foram git log, git reflog e git checkout.