Como você corrige um “HEAD separado” em um repositório Git?

Uma das mensagens de erro regulares que você provavelmente encontrará com o Git é o aviso de que “ você está no & # 8216; HEAD desanexado &’ estado. ” Você pode ter tropeçado nisso acidentalmente, mas não se preocupe, é um problema normal e pode ser facilmente corrigido assim que você entender o que significa.

O que é o Git HEAD?

“ CABEÇA ” é simplesmente um apelido para seu commit de trabalho atual, muito parecido com seu diretório atual em uma linha de comando. Qualquer que seja o estado do seu repositório Git, o HEAD sempre aponta para algo, e novos commits serão anexados na frente do HEAD.

Normalmente, o HEAD não faz referência direta a um único commit. Em vez disso, ele aponta para um branch e indiretamente faz referência ao commit mais recente naquele branch. Sempre que você “ finalizar a compra ” um novo branch, Git muda o HEAD para aquele branch. Isso permite que você faça novos commits que serão anexados ao final desse branch.

No entanto, você também pode verificar commits individuais. E se você quisesse examinar o repositório em um momento específico? Essa é uma das maiores vantagens do Git, mas apresenta um pequeno problema de como o Git estrutura as coisas. Uma vez que novos commits não atualizam um branch, quaisquer commits que você fizer após mover o HEAD para longe serão desanexados de todas as referências do branch, portanto, “ desanexou HEAD. ”

Isso pode ser bastante útil. Digamos que você moveu o HEAD de volta alguns commits, e então fez algumas atualizações experimentais. Você está basicamente fazendo um novo branch, que pode ser mesclado de volta ao master mais tarde.

Publicidade

Você precisará integrá-lo oficialmente ao repositório Git se decidir manter as alterações, mas como uma ferramenta para fazer modificações no passado, ter um HEAD separado não é tão assustador como parece.

Se você chegou aqui por acidente

É muito fácil acabar aqui sem querer e ficar confuso com a mensagem de erro da qual Git está reclamando, apesar de não ter feito nada de errado. Felizmente, é incrivelmente fácil de consertar:

Se você acabou de verificar um commit e não tocou no repositório de outra forma (nenhum commit foi feito), você pode simplesmente mover o HEAD de volta para onde ele pertence com git checkout:

 git checkout master 

Isso é basicamente como rodar cd no Linux, exceto que o Git ainda associa commits e mudanças em cache com o HEAD antigo, então você não quer verificar se tem commits ou mudanças que seriam deixadas penduradas.

Se você fez algumas alterações e deseja apenas descartá-las, pode reinicializar o hardware de volta para mestre:

 git reset --hard origin / master git clean -d --force 

Se você quiser salvar seus commits, porém, você precisará fundi-los oficialmente de volta na linha do tempo do Git.

Se você deseja salvar suas alterações

A primeira coisa que você vai querer fazer se quiser manter as mudanças que fez enquanto estava no estado HEAD desanexado é fazer um novo branch. Isso ocorre porque o coletor de lixo do Git limpará os commits desanexados automaticamente, então você nunca vai querer perdê-los.

 git branch detached-branch 

Publicidade

Então você pode verificar este branch para mover o HEAD para que ele não seja mais desanexado e, em vez disso, apontado para este novo branch oficial:

 git checkout detached-branch 

Assim que as alterações forem registradas, você terá uma de duas opções. Este novo branch é basicamente um branch de recurso comum, então você pode git merge ou git rebase.

A mesclagem é direta; checkout master e mesclar o branch desanexado:

 git checkout master git merge detached-branch 

Isso funciona bem se você estiver se integrando a um branch que precisa de aprovação, como é o caso com solicitações pull e revisões de código. Pode ser necessário passar pelo processo de aprovação de sua equipe em vez de executar esses comandos você mesmo.

Se você tiver acesso, por exemplo, se você estiver mesclando de volta em um branch de recurso no qual está trabalhando, um método melhor é escolher os commits desanexados . O Cherry picking basicamente copia um commit e o cola em outro branch. Geralmente é usado para extrair commits específicos de um branch de recurso antes que tudo esteja pronto, mas, neste caso, a seleção seletiva pode reconciliar o branch desanexado sem uma fusão.

Publicidade

Neste exemplo, o commit acima está desanexado. Em vez de mesclá-lo, ele é escolhido a dedo e movido para a ramificação do recurso. Isso move o HEAD e o branch do recurso para apontar para o commit mais recente sem uma fusão. Em seguida, o commit original desanexado pode ser descartado.

Primeiro, você precisará fazer o branch desanexado e, em seguida, verificar o branch do recurso para mover o HEAD para lá:

 recurso git branch detached-branch checkout do git 

Em seguida, execute Git log para obter uma lista de commits:

 git log --pretty = format: "% h% s" --graph 

Então você pode escolher um commit por seu ID:

 git cherry-pick 1da76d3 

Então, uma vez que você tenha confirmado que os commits escolhidos a dedo são aplicados corretamente, você pode deletar o branch desanexado, já que os commits foram copiados e não são mais usados.

 git branch -D detached-branch 

Rebasing em vez de mesclar

Você também pode fazer um rebase. Rebases são diferentes de mesclagens porque reescrevem o histórico do branch, levantando os commits desanexados e movendo-os para a frente do branch.

No entanto, o problema com isso é que você ainda tem dois branches, e ainda precisará mesclar feature e desanexado branch, deixando-o com um commit de fusão de qualquer maneira. Mas, isso deixa o repositório com um histórico Git mais linear, que é preferível a executar git merge se você tiver autoridade para fazer isso.


  • [👑 Desbloqueie postagens e links premium sem Anúncio ]
    Para conseguir pegar o link no protetor basta aguardar 15 segundos.. ou Ativar acesso Premium.   Ativar acesso Premium CLIQUE AQUI!

    Deixe um comentário

    O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *