Written by 20:47 Desenvolvimento Views: 146

10 problemas comuns do Git e como corrigi-los

Aprendendo Git? Este tutorial aborda os 10 truques mais comuns do Git que você deve conhecer: como desfazer confirmações, reverter confirmações, editar mensagens de confirmação, descartar arquivos locais, resolver conflitos de mesclagem e muito mais.

1. Descartar modificações em arquivos locais

Às vezes, a melhor maneira de perceber um problema é mergulhar fundo e mexer com o código. 

Infelizmente, vez ou outra as alterações feitas no processo acabam ficando abaixo do ideal. Nesse caso, a reversão do arquivo para seu estado original pode ser a solução mais rápida e fácil:

Caso você esteja se perguntando, o traço duplo (–) é uma maneira comum dos utilitários da linha de comando significarem o final das opções de comando.

2. Desfazer commits locais

Às vezes, demoramos um pouco mais para perceber que estamos no caminho errado e, nesse tempo, uma ou mais mudanças já podem ter sido feitas localmente. 

É aí que o git reset chega para dar uma mãozinha: 

Tenha cuidado com a opção –hard! Ela redefine sua árvore de trabalho e o índice, para que todas as suas modificações sejam removidas definitivamente.

3. Remova um arquivo do git sem removê-lo do seu sistema de arquivos

Se você não tiver cuidado durante um git add, pode acabar adicionando um arquivo que não deseja.

No entanto, o git rm irá removê-lo da área de armazenamento temporário e do sistema de arquivos, o que pode não ser o que você deseja. 

Nesse caso, remova apenas a versão da área de preparação e adicione o arquivo ao seu .gitignore para evitar cometer o mesmo erro pela segunda vez:

4. Edite uma mensagem de commit

Erros de digitação acontecem, mas, felizmente, no caso de mensagens de commit é muito fácil corrigi-los:

Mas isso não é tudo o que o git-amend pode fazer por você. Acabou esquecendo de inserir um arquivo? Basta adicioná-lo e alterar o commit anterior. 

Lembre-se de que –amend na verdade irá criar um novo commit, que substitui a versão anterior, portanto, não use para modificar commits que já foram enviados para um repositório central. 

Uma exceção a essa regra pode ser feita se você tiver certeza absoluta de que nenhum outro/a dev já fez o check-out da versão anterior e tenha baseado seu próprio trabalho nela; nesse caso, um push forçado (git push –force) ainda pode ser ok.  

A opção –force é necessária aqui, pois o histórico da árvore foi modificado localmente, o que significa que o envio será rejeitado pelo servidor remoto, pois não é possível uma mesclagem de avanço rápido.

5. Limpe os commits locais antes de fazer o push

Embora –amend seja muito útil, não ajuda se o commit que você deseja reformular não for o último. 

Nesse caso, um rebase interativo pode ser útil: 

Isso abrirá o editor configurado e apresentará o seguinte menu:

No topo, você verá uma lista de commits locais, seguidos de uma explicação dos comandos disponíveis. 

Basta escolher o(s) commit(s) que deseja atualizar, alterar o pick para reword (ou r para abreviar) e você será direcionado/a para uma nova exibição na qual poderá editar a mensagem.

No entanto, como pode ser visto na lista acima, as rebases interativas oferecem muito mais do que a simples edição de mensagens de commit: você pode remover completamente os commits, excluindo-os da lista, bem como editá-los, reordená-los e fazer o squash de commits. 

O squash permite mesclar vários commits em um, o que é algo que eu gosto de fazer nas ramificações de recursos antes de enviá-las para o controle remoto. 

Chega de “adicionar arquivo esquecido” e “corrigir erros de digitação” nos commits para sempre.

6. Revertendo o push de commits

Apesar das correções demonstradas nas dicas anteriores, commits defeituosos ocasionalmente chegam ao repositório central. 

Ainda assim, este não é um motivo para se desesperar, pois o git oferece uma maneira fácil de reverter um ou vários commits:

Caso não deseje criar commits adicionais de reversão, mas apenas aplicar as alterações necessárias à sua árvore de trabalho, você pode usar a opção –no-commit / -n

A página de manual no man 1 git-revert lista outras opções e fornece alguns exemplos adicionais.

7. Evite conflitos repetidos de mesclagem

Como todo/a dev sabe, a correção de conflitos de mesclagem pode ser entediante, mas resolver o mesmo conflito repetidamente (por exemplo, em ramos de recursos de longa execução) é totalmente irritante. 

Se você sofreu com isso no passado, ficará feliz em saber sobre o recurso de resolução gravada de reutilização subutilizada. Adicione-o à sua configuração para habilitá-lo para todos os projetos:

Como alternativa, você pode habilitá-lo por projeto, criando manualmente o diretório .git / rr-cache.

Este certamente não é um recurso para todos/as, mas, para as pessoas que precisam, ele garante economia real de tempo. 

Imagine que sua equipe esteja trabalhando em vários ramos de recursos ao mesmo tempo. Agora você deseja mesclar todos eles em um ramo de pré-lançamento testável. 

Como esperado, existem vários conflitos de mesclagem que você resolve. Infelizmente, um dos ramos ainda não está lá, então você decide retirá-lo da mesclagem. 

Vários dias (ou semanas) depois, quando a ramificação estiver finalmente pronta, você a mesclará novamente, mas, graças às resoluções registradas, não será necessário resolver os mesmos conflitos de mesclagem de novo.

A man page (man git-rerere) tem mais informações sobre outros casos de uso e comandos (git rerere status, git rerere diff, etc).

8. Encontre o commit que quebrou algo após uma mesclagem

Rastrear o commit que introduziu um bug após uma grande mesclagem pode consumir bastante tempo. Felizmente, o git oferece um ótimo recurso de pesquisa binária na forma de git-bisect

Primeiro você precisa executar a configuração inicial: 

Depois esse git fará automaticamente o check-out de uma revisão entre as versões “boa” e “ruim” conhecidas. 

Agora você pode executar suas especificações novamente e marcar o commit como “bom” ou “ruim” adequadamente.

Esse processo continua até você encontrar o commit que introduziu o bug.

9. Evite erros comuns com git hooks

Alguns erros ocorrem repetidamente, mas seria fácil evitá-los com a execução de determinadas verificações ou tarefas de limpeza em um estágio definido do fluxo de trabalho do git. 

Este é exatamente o cenário para o qual os hooks foram projetados. 

Para criar um novo hook, adicione um arquivo executável ao .git / hooks. O nome do script deve corresponder a um dos hooks disponíveis, cuja lista completa está na página de manual (man githooks). 

Você também pode definir hooks globais para usar em todos os seus projetos, criando um diretório de templates que o git usará ao inicializar um novo repositório (consulte man git-init para obter mais informações). 

Veja como é a entrada relevante em ~ / .gitconfig e um diretório de template de exemplo:

Quando você inicializa um novo repositório, os arquivos no diretório de templates são copiados para o local correspondente no diretório .git do seu projeto.

A seguir, é apresentado um exemplo de commit-msg hook, que garantirá que toda mensagem de commit faça referência a um número de ticket como “# 123”

10. Quando tudo falhar

Até agora, discutimos bastante sobre como corrigir erros comuns ao trabalhar com o git. A maioria deles tem soluções fáceis o suficiente, no entanto, há momentos em que é preciso pegar as grandes armas e reescrever a história de um ramo inteiro. 

Um caso de uso comum para isso é remover dados confidenciais (por exemplo, credenciais de login para sistemas de produção) que foram confirmados em um repositório público: 

Isso irá remover o arquivo secrets.txt de cada ramificação e tag. Ele também removerá quaisquer commits que estejam vazios como resultado da operação acima. 

Lembre-se de que isso vai reescrever todo o histórico do seu projeto, o que pode ser muito disruptivo em um fluxo de trabalho distribuído. 

Além disso, embora o arquivo em questão tenha sido removido, as credenciais que ele continha ainda devem ser consideradas comprometidas!

O GitHub tem um tutorial muito bom sobre a remoção de dados confidenciais e o man git-filter-branch tem todos os detalhes sobre os vários filtros disponíveis e suas opções.

Leia também: Comandos Git: os principais para otimizar seus processos

Este é um artigo traduzido, você pode acessar a versão original em inglês aqui.
Todos os créditos para o autor: Michael Kohl

(Visited 146 times, 1 visits today)

Last modified: 03/06/2020

Close