Estou procurando as informações básicas sobre commits e blobs pendurados.
Meu repo parece bem. Mas eu corri git fsckpela primeira vez para ver o que fazia e tenho uma longa lista de 'blobs pendentes' e um único 'commit pendente'.
O que são essas coisas? De onde eles vieram? Eles indicam algo incomum (bom ou ruim) sobre o estado do meu repo?
Respostas:
Durante o trabalho com seu repositório git, você pode acabar saindo das operações e fazendo outras movimentações que causam blobs intermediários, e até algumas coisas que o git faz por você para ajudar a evitar a perda de informações.
Eventualmente (condicionalmente, de acordo com a página de manual do git gc ), ele executará a coleta de lixo e limpará essas coisas. Você também pode forçá-lo invocando o processo de coleta de lixo git gc,.
Para obter mais informações sobre isso, consulte Manutenção e recuperação de dados no site git-scm.
Uma execução manual do GC sairá por padrão 2 semanas antes do tempo de execução deste comando de uma rede de segurança. De fato, é recomendável executar o GC ocasionalmente para ajudar a garantir o desempenho do seu repositório git. Porém, como qualquer coisa, você deve entender o que está fazendo antes de destruir as coisas que podem ser importantes para você.
Dangling blob = Uma alteração que chegou à área / índice de preparação, mas nunca foi confirmada. Uma coisa que é surpreendente com o git é que, uma vez adicionado à área de preparação, você sempre pode recuperá-lo, porque esses blobs se comportam como confirmados por terem um hash também !!
Confirmação dangling = uma confirmação que não está diretamente vinculada a nenhuma confirmação filho, ramificação, tag ou outra referência. Você pode recuperá-los também!
COMO remover todos os commits dangling do seu repositório git de http://www.tekkie.ro/news/howto-remove-all-dangling-commits-from-your-git-repository/
git reflog expire --expire=now --all
git gc --prune=now
Verifique se realmente deseja removê-los, pois você pode decidir que precisa deles, afinal.
Um commit dangling é um commit que não está associado à referência, ou seja, não há como alcançá-lo.
Por exemplo, considere o diagrama abaixo. Suponha que excluamos o recurso featureX sem mesclar suas alterações, e o commit D se tornará um commit pendente porque não há nenhuma referência associada a ele. Se ele tivesse sido mesclado no master, as referências HEAD e master teriam apontado para confirmar D e ele não estaria mais danificado, mesmo que excluíssemos o featureX. Leia a nota após o diagrama para entender melhor isso.
O Git coleta automaticamente de lixo (ou seja, descarta) comprometimentos pendentes. Podemos usar o git reflogpara recuperar um ramo (de confirmações pendentes) que foi excluído sem mesclá-lo. Só podemos recuperar confirmações excluídas se ele estiver presente no armazenamento de objetos local. Se o lixo foi coletado, não podemos recuperá-lo.
Observe que o nome de uma ramificação, ou seja, o rótulo da ramificação, é na verdade uma referência à confirmação mais recente em uma ramificação, ou seja, a ponta da ramificação. No diagrama acima, featureX, master e HEAD são apenas referências a confirmações específicas. featureX e master labels referem-se às confirmações mais recentes em suas respectivas ramificações. HEAD geralmente se refere à ponta do ramo atualmente com check-out (mestre neste caso). Se você efetuar o check-out de um commit mais antigo em sua ramificação atual, o HEAD estará em um estado desanexado, ou seja, ele apontará para o commit mais antigo, em vez do mais recente. Observe também que HEAD é chamado de referência simbólica porque, na verdade, aponta para o rótulo da ramificação atual e qualquer rótulo da ramificação sempre aponta para a ponta da ramificação. Portanto, em circunstâncias normais, o HEAD indica indiretamente o último commit.
Como um aparte, observe que o Git representa seu gráfico / histórico de confirmação como um gráfico acíclico direcionado . Cada confirmação tem uma referência ao pai. Portanto, as setas em um diagrama de confirmação apontam de confirmação filho para confirmação pai. Precisamos de uma referência ao commit filho mais recente para alcançar os commit mais antigos em um branch.
PS - O diagrama e entendimento acima foram obtidos neste curso gratuito . Embora o curso seja bastante antigo, o conhecimento ainda é relevante.
git gce 2) Eu não preciso me preocupar com isso, porque esses bits pendentes são normais e já estão com o git lidar com eles?