Verificando um commit antigo e mantendo o head no branch master?

Atualmente, para mudar para outro commit git (no mesmo branch ... na verdade, no branch master!), Estou executando o comando

git checkout ea3d5ed039edd6d4a07cc41bd09eb58edd1f2b3a

Agora, toda vez que faço isso, o idiota me diz que agora estou com uma cabeça separada. Como vou para um commit mais antigo e ainda mantenho o head no mesmo branch?

Na maioria das vezes, quando faço isso, faço checkout em um branch temporário:

git checkout -b temp-branch-name ea3d5ed039edd6d4a07cc41bd09eb58edd1f2b3a

Então, depois de terminar, eu apenas excluo o ramo

Depende do que você deseja fazer ao finalizar o commit. Se tudo o que você está fazendo é verificar para que possa construir ou testar essa revisão, não há nada de errado em trabalhar com um cabeçote destacado. Apenas lembre-se de verificar um branch real antes de fazer qualquer commit ( git checkout masterpor exemplo), para que você não crie commits que não estão incluídos em nenhum branch.

Se, no entanto, você deseja fazer mais commits a partir desse ponto, você deve criar um branch. Se você fizer commits que não são referenciados por um branch, eles podem facilmente se perder e, eventualmente, serão limpos pelo coletor de lixo do git, já que nada se refere a eles. Você pode criar um novo branch executando:

git checkout -b newbranch ea3d5ed

Para ajudar a visualizar, aqui estão alguns diagramas que demonstram como trabalhar em um cabeçote destacado difere de trabalhar em um galho.

Vamos começar com 3 commits em master, A, B e C. masteré o branch atual, então HEADaponta para master, que aponta para o commit C.

abc
* - * - * <- mestre <- CABEÇA

Agora, se fizermos um commit, git criará um commit que tem C como pai (porque esse é o commit atual, apontado por HEADvia master), e atualizará masterpara apontar para esse novo commit. Todos os nossos commits estão agora ativados mastere HEADapontam para o novo commit master.

ABCD
* - * - * - * <- mestre <- CABEÇA

Agora vamos verificar B, nos dando um destacado HEAD.

ABCD
* - * - * - * <- mestre
   ^
    \ - CABEÇA

Tudo funciona bem aqui; podemos ver todos os arquivos, construir nosso programa, testá-lo, etc. Podemos até criar novos commits; mas se fizermos isso, não há nenhum branch no qual estamos, então não podemos apontar nenhum branch para aquele novo commit. A única coisa que aponta para isso é HEAD:

ABCD
* - * - * - * <- mestre
    \
     * <- CABEÇA
     E

Se mais tarde decidirmos fazer check-out masternovamente, não haverá nada referente a E.

ABCD
* - * - * - * <- mestre <- CABEÇA
    \
     *
     E

Já que não há nada referindo-se a isso, pode ser difícil de encontrar, e git considera os commits sem referências a serem abandonados (eles acontecem muito comumente se você rebase, ou esmaga patches, ou faz outra manipulação divertida de histórico; eles geralmente representam patches abandonados que você não se preocupa mais). Depois de um certo tempo, o git irá considerá-lo lixo, para ser descartado na próxima vez que a coleta de lixo for executada.

Então, ao invés de fazer check-out de uma revisão simples e obter uma cabeça separada, se você sentir que vai fazer mais commits, você deve usar git checkout -b branch Bpara criar um branch e fazer o check-out. Agora seus commits não serão perdidos, pois eles serão incluídos em um branch, ao qual você pode facilmente consultar e fundir mais tarde.

ABCD
* - * - * - * <- mestre
   ^
    \ - branch <- HEAD

Se você esquecer de fazer isso e criar commits de um branch, não há necessidade de se preocupar. Você pode criar um ramo referindo-se à revisão do cabeçote com git checkout -b branch. Se você já voltou para o masterbranch e percebeu que esqueceu um commit perdido, você pode encontrá-lo usando o git reflog, que irá mostrar um histórico do que os commits HEADapontaram nos últimos dias. Tudo o que ainda está no reflog não será coletado como lixo e, geralmente, as referências são mantidas no reflog por pelo menos 30 dias.

Se você simplesmente deseja retornar a um commit anterior para brincar com ele sem fazer nenhuma alteração, você pode fazer

git co <previous-commit-id>

você estará em um branch chamado "(no branch)" após este comando.

Confirme isso por

git br

Depois de jogar com este código previamente confirmado, você pode mudar para o branch em que estava

git co <the-branch-you-were-on>

O "(sem ramificação)" será excluído automaticamente. Desta forma, você não precisa criar um branch temporário.

O HEAD do Git é simplesmente um ponteiro que diz o que está no diretório de trabalho. Se você quiser verificar um commit que não é o chefe de um branch, você simplesmente tem que redirecionar seu HEAD para apontar para aquele commit. Não há como contornar isso. Você pode criar um branch temporário naquele commit, mas HEAD será direcionado para longe do master mesmo assim.

Essa é a explicação curta. O detalhamento a seguir, com sorte, ajudará a entender como o HEAD e o master são diferentes:

Normalmente, as coisas se parecem com isto:

C ← refs/heads/master ← HEAD 
↓
B
↓
A

O que quer dizer: “O pai de C é B, e o pai de B é A. O branch master está apontando para C, e atualmente verifiquei o conteúdo do master. Além disso, quando eu me comprometer, o mestre deve ser atualizado. ”

Algumas suposições estão implícitas nisso, as quais são necessárias para um entendimento completo do gráfico de confirmação. Ou seja, commits referem-se apenas a seus pais, e o conteúdo de um branch são aqueles commits (e apenas aqueles commits) que podem ser alcançados seguindo os links pais. O conteúdo (não modificado) da árvore de trabalho e do índice deve corresponder ao commit nomeado por HEAD, seja indiretamente (“simbólico”) ou diretamente (“destacado”).

Portanto, se você quiser verificar um commit antigo, o HEAD deve ser atualizado para apontar para o commit desejado. git-checkoutfaz exatamente isso:

C ← refs/heads/master 
↓
B ← HEAD
↓
A

Agora, você deixou seu galho para trás, já que está olhando para algo antigo. Isso está perfeitamente OK, como o conselho da "cabeça destacada" diz com calma (ênfase minha):

Você pode olhar ao redor, fazer mudanças experimentais e confirmá-las, e você pode descartar qualquer confirmação que você fizer neste estado sem impactar qualquer branch ao realizar outra verificação.

Por outro lado, embora a redefinição do seu branch também leve o HEAD onde ele precisa estar, teria um efeito muito diferente!

C
↓
B ← refs/heads/master ← HEAD
↓
A

O commit C se tornará lixo, já que você declarou que não deseja mais que ele faça parte do branch master.

Resumindo, tudo que você precisa fazer é entender o que o git quer dizer com “HEAD” - é onde você está, não onde um determinado branch está. E se onde você está não é o mesmo que onde está uma ramificação, não há escolha a não ser usar um HEAD separado.

(Talvez também procure no GitHub, gitk ou gitweb para navegar no histórico de commits, se o descarrilamento do HEAD continuar a irritá-lo.)

A pergunta é um pouco vaga, mas se você deseja apenas alterar os arquivos em sua árvore de trabalho, você pode simplesmente fazer o seguinte:

git checkout [commit|branch] -- .

Você pode então preparar as mudanças e criar um novo commit, se desejar. Isso é muito útil às vezes.

Acho que entendo suas perguntas. Aqui está o que eu encontrei para resolver isso. e não há solução GUI para isso, você só pode usar o comando para resolvê-lo, e é muito simples.

passo 1: crie uma tag do commit antigo que você deseja voltar.

como tag v2.0

etapa 2: git checkout v2.0

aqui está, agora seu HEAD está apontando para o commit 'v2.0', mas o master ainda está apontando para o último commit.

C:\Program Files\Git\doc\git\html\git-checkout.html este documento pode te ajudar

ou digite git help <checkout>