Git Reflog
Esta página apresenta informações sobre o comando git reflog. O Git monitora as atualizações das pontas das ramificações com um mecanismo chamado logs de referência ou "reflogs". Muitos comandos do Git aceitam um parâmetro para especificar uma referência ou "ref", que é um indicador de um commit. Exemplos comuns incluem:
Os reflogs monitoram quando referências do Git são atualizadas no repositório local. Além de reflogs de pontas de ramificações, é mantido um reflog especial para o Git stash. Os reflogs são armazenados em diretórios sob o diretório .git do repositório local. Os diretórios do git reflog podem ser encontrados em .git/logs/refs/heads/., .git/logs/HEAD e também .git/logs/refs/stash se o git stash tiver sido usado no repositório.
Falamos bastante sobre o git reflog na página Como reescrever o histórico. Este documento cobre: opções de configuração aprofundadas do git reflog, funções comuns e armadilhas do git reflog, como desfazer alterações com o git reflog, e mais.
Função básica
A função mais básica do Reflog é a invocação:
git reflogEm resumo, é um atalho equivalente a:
git reflog show HEADEsse comando vai emitir o reflog do HEAD. Você vai visualizar algo como:
eff544f HEAD@{0}: commit: migrate existing content
bf871fd HEAD@{1}: commit: Add Git Reflog outline
9a4491f HEAD@{2}: checkout: moving from main to git_reflog
9a4491f HEAD@{3}: checkout: moving from Git_Config to main
39b159a HEAD@{4}: commit: expand on git context
9b3aa71 HEAD@{5}: commit: more color clarification
f34388b HEAD@{6}: commit: expand on color support
9962aed HEAD@{7}: commit: a git editor -> the Git editor
Material relacionado
Folha de consulta do Git
VER SOLUÇÃO
Aprenda a usar o Git com o Bitbucket Cloud
Visite a página Como escrever o histórico para ver outro exemplo de acessos comuns do reflog.
Referências do reflog
O DevOps aborda todas as fases do ciclo de vida de desenvolvimento e operações. Do planejamento e criação ao monitoramento e iteração, o DevOps reúne as habilidades, os processos e as ferramentas de todas as facetas de uma organização de engenharia e TI.
As metodologias ágeis ajudam as equipes a planejar e produzir por meio da divisão do trabalho em tarefas e marcos gerenciáveis. A agilidade conta com sprints, backlogs, epics e histórias para atribuir trabalhos a membros qualificados da equipe, ajustar cronogramas quando necessário e disponibilizar produtos e serviços de qualidade aos clientes. Saiba mais sobre a agilidade.
Integração e entrega contínuas: são a base das práticas de DevOps que contam com a automação da mesclagem e implementação de código. Os métodos de desenvolvimento tradicionais exigem que os engenheiros atualizem as alterações na base de código com verificações manuais adicionais para garantir que o código de qualidade esteja pronto para ser lançado em produção. As implementações são agendadas com atrasos de semanas ou meses para eliminar a probabilidade de erros ou incidentes. As práticas de DevOps eliminam esses atrasos automatizando as funções de mesclagem, teste e implementação. Equipes de alto desempenho usam a integração contínua/implementação contínua (IC/CD) para reduzir a frequência de implementação de alguns meses para várias vezes ao dia. Saiba mais sobre integração contínua/implementação contínua (IC/CD).
Os repositórios e fluxos de trabalho do Git proporcionam os recursos de automação e controle de versão que são fundamentais para as práticas de DevOps. Como o Git é distribuído, operações como commit, blame, diff, merge e log acontecem com mais rapidez. Ele também suporta ramificação, mesclagem e reescrita do histórico do repositório, o que proporciona ferramentas e fluxos de trabalho poderosos. Saiba mais sobre o Git.
Gerenciamento de serviços de TI é o processo que as equipes de TI usam para gerenciar a entrega de ponta a ponta de serviços de TI aos clientes. Todos os processos e atividades de projeto, criação, entrega e suporte a serviços de TI estão inclusos. O conceito central do ITSM é a crença de que a TI deve ser fornecida como um serviço, o que vai além do suporte básico de TI. As equipes de ITSM supervisionam tecnologias de local de trabalho dos mais variados tipos, desde notebooks a servidores e aplicativos de software essenciais para os negócios. Saiba mais sobre ITSM.
As equipes de gerenciamento de incidentes respondem a um evento ou interrupção de serviço não planejados para restaurar o serviço ao estado operacional. Em um modelo “você cria, você executa”, os desenvolvedores fazem parceria com as operações para reduzir a probabilidade de ocorrência de um incidente e o tempo médio de recuperação quando um incidente acontece. Saiba mais sobre gerenciamento de incidentes.
Por padrão, o git reflog vai gerar o reflog da referência do HEAD. O HEAD é uma referência simbólica à ramificação ativa no momento. Os reflogs também estão disponíveis para outras referências. A sintaxe para acessar uma referência do git é nome@{qualificador}. Além de referências do HEAD, outras ramificações, tags, remotos e o Git stash também podem ser referenciados.
Você pode obter um reflog completo de todas as referências ao executar:
git reflog show --all
Para ver o reflog de uma ramificação específica, transfira o nome dessa ramificação para git reflog show
Bitbucket displays the Create a new repository page. Take some time to review the dialog's contents. With the exception of the Repository type, everything you enter on this page you can later change.
git reflog show otherbranch
9a4491f otherbranch@{0}: commit: seperate articles into branch PRs
35aee4a otherbranch{1}: commit (initial): initial commit add git-init and setting-up-a-repo docsA execução desse exemplo vai mostrar um reflog para a ramificação otherbranch. O exemplo a seguir presume que você já fez stash de algumas alterações com o comando git stash.
git reflog stash
0d44de3 stash@{0}: WIP on git_reflog: c492574 flesh out introEssa ação vai gerar um reflog do Git stash. Os indicadores de referência que retornaram podem ser transmitidos a outros comandos do Git:
git diff stash@{0} otherbranch@{0}Quando executado, esse código de exemplo vai exibir os resultados do Git diff comparando as alterações de stash@{0} em relação à referência da otherbranch@{0}.
Reflogs temporizados
Todas as entradas de reflog têm um registro de tempo anexado. Esses registros podem ser aproveitados como o token qualificador da sintaxe do indicador de referência do Git. Ele permite que os reflogs do Git sejam filtrados pelo tempo. Os exemplos a seguir mostram qualificadores temporais disponíveis:
1.minute.ago1.hour.ago1.day.agoyesterday1.week.ago1.month.ago1.year.ago2011-05-17.09:00:00
Os qualificadores temporais podem ser combinados (por exemplo, 1.day.2.hours.ago), Formas no plural também são aceitas (por exemplo, 5.minutes.ago).
Referências de qualificadores temporais podem ser transmitidas a outros comandos do git.
git diff main@{0} main@{1.day.ago} Esse exemplo diferencia o branch principal atual do branch principal de 1 dia atrás. É muito útil se você quiser saber quais alterações ocorreram dentro de certo período.
Subcomandos e opções de configuração
O git reflog aceita alguns argumentos adicionais que são considerados subcomandos.
Show - git reflog show
A transmissão de show é implícita por padrão. Por exemplo, o comando:
git reflog main@{0} equivale ao comando:
git reflog show main@{0}
Ainda, o git reflog show é um alias para git log -g --abbrev-commit --pretty=oneline. A execução do git reflog show vai exibir o log para o
Expire - git reflog expire
O subcomando expire limpa entradas de reflog antigas ou inacessíveis. O subcomando expire pode acarretar perda de dados e não é usado com frequência pelos usuários finais, apenas pelo git em contexto interno. A execução de uma opção -n ou --dry-run para o git reflog expire vai realizar um "dry run" que vai exibir quais entradas de reflog estão marcadas para limpeza, mas não vai realizar a ação de fato.
Por padrão, o prazo de validade dos reflogs é de 90 dias. O prazo de validade pode ser definido pela transmissão de um argumento de linha de comando --expire=time para o git reflog expire ou pela definição de um nome de configuração do git para gc.reflogExpire.
Delete - git reflog delete
O subcomando delete é autoexplicativo e vai excluir uma entrada de reflog que foi transmitida. Assim como o expire, o delete pode acarretar perda de dados e não é invocado com frequência por usuários finais.
Como recuperar commits perdidos
O Git jamais perde algo, mesmo durante operações de reescrita de histórico como rebase ou correção de commits. Em relação ao próximo exemplo, faz de conta que a gente alterou algumas coisas no repositório. O git log --pretty=oneline está mais ou menos assim:
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsDepois, a gente dá commit nessas alterações e executa o seguinte:
#make changes to HEAD
git commit -am "some WIP changes"É mais ou menos assim que o log fica após a adição do commit novo:
$ git clone
https://emmap1@bitbucket.org/emmap1/bitbucketstationlocations.git
Cloning into 'bitbucketspacestation'...
fatal: could not read
Password for 'https://emmap1@bitbucket.org': No such file or directorySe esse erro for exibido, digite o seguinte na linha de comando:
37656e19d4e4f1a9b419f57850c8f1974f871b07 some WIP changes
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsNesse ponto, realizaremos um rebase interativo no branch principal por meio da execução de...
git rebase -i origin/mainDurante o rebase, os commits são marcados para squash com o subcomando s de rebase. Nesse processo, alguns commits passam por squash para o commit "algumas alterações de WIP" mais recente.
Devido ao squash dos commits, a definição do git log fica mais ou menos assim:
40dhsoi37656e19d4e4f1a9b419f57850ch87dah987698hs some WIP changes
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsAnalisando o git log nesse ponto, parece que os commits marcados para squash não existem mais. E se a gente quiser operar em um dos commits que passaram por squash? Talvez para excluir as alterações do histórico? É uma oportunidade para usar o reflog.
git reflog
37656e1 HEAD@{0}: rebase -i (finish): returning to refs/heads/git_reflog
37656e1 HEAD@{1}: rebase -i (start): checkout origin/main
37656e1 HEAD@{2}: commit: some WIP changesÉ possível ver que existem entradas de reflog para o início e o fim do rebase e o commit de "algumas alterações de WIP" antes delas. É possível transferir a referência do reflog para o git reset e redefinir para um commit que existia antes do rebase.
git reset HEAD@{2}A execução desse comando de redefinição vai transferir o HEAD para o commit a que o "algumas alterações de WIP" foi adicionado, restaurando, em essência, os outros commits que passaram por squash.
Resumo
Neste tutorial, a gente falou sobre o comando git reflog. Alguns dos principais pontos apresentados foram:
- Como visualizar o reflog de ramificações específicas
- Como desfazer um rebase do git com o reflog
- Como definir e visualizar entradas de reflog temporizadas
We briefly mentioned that git reflog can be used with other git commands like git checkout, git reset, and git merge. Learn more at their respective pages. For additional discussion on refs and the reflog, learn more here.
Compartilhar este artigo
Próximo tópico
Leitura recomendada
Marque esses recursos para aprender sobre os tipos de equipes de DevOps ou para obter atualizações contínuas sobre DevOps na Atlassian.
Blog do Bitbucket
Caminho de aprendizagem de DevOps
