Nota perev. : Alguns dias atrás, uma anotação pequena, mas muito útil, apareceu no blog para engenheiros do nosso projeto favorito do GitLab, com instruções que ajudam a economizar tempo e nervosismo no caso de vários problemas que ocorrem quando você trabalha com o Git. É improvável que eles sejam novos para usuários experientes, mas certamente haverá aqueles para quem eles serão úteis. E no final deste material, adicionamos um pequeno bônus de nós mesmos. Tenham uma boa sexta-feira!Todos cometemos erros, principalmente quando trabalhamos com sistemas complexos como o Git. Mas lembre-se: Git acontece!
Se você está apenas começando com o Git, aprenda o
básico sobre como trabalhar com ele na linha de comando. E aqui vou falar sobre como você pode corrigir os seis erros mais comuns no Git.
1. Opa ... Eu estava enganado na mensagem até o último commit
Após várias horas de codificação, é fácil cometer um erro na mensagem de confirmação. Felizmente, isso é fácil de corrigir:
git commit --amend
Com este comando, um editor de texto será aberto e permitirá que você faça alterações na mensagem até a última confirmação. E ninguém saberá que você escreveu "adicionado" com três "ds".
2. Ops ... esqueci de adicionar o arquivo ao último commit
Outro bug popular no Git é um commit muito apressado. Você esqueceu de adicionar o arquivo, esqueceu de salvá-lo ou deve fazer uma pequena alteração para tornar o commit significativo? Seu amigo será -
--amend novamente.
Adicione o arquivo ausente e execute este comando correto:
git add missed-file.txt git commit --amend
Agora você pode corrigir a mensagem ou simplesmente salvá-la em sua forma original (com o arquivo adicionado).
3. Opa ... Adicionei um arquivo que não deve estar neste repositório
Mas e se você tiver a situação oposta? E se você adicionou um arquivo que não deseja confirmar? Um arquivo ENV enganoso, cria diretório ou foto com um gato que foi salvo acidentalmente no diretório errado ... Tudo está resolvido.
Se você fez apenas o
estágio do arquivo e ainda não o confirmou, tudo é feito através de uma
redefinição simples
do arquivo desejado (localizado no estágio):
git reset /assets/img/misty-and-pepper.jpg
Se você ainda confirmar a alteração, será necessária uma etapa preliminar adicional:
git reset --soft HEAD~1 git reset /assets/img/misty-and-pepper.jpg rm /assets/img/misty-and-pepper.jpg git commit
A confirmação será revertida, a imagem será excluída e, em seguida, uma nova confirmação será feita.
Nota perev. : Como observado nos comentários no artigo original, esse problema também pode ser resolvido usando o - --amend já mencionado. Aparentemente, com este parágrafo, o autor queria mostrar o que mais existem maneiras de alterar o histórico de confirmações para corrigir o erro.4. Opa ... Eu cometi alterações no master
Então, você está trabalhando em um novo recurso e se apressou, esquecendo de criar um novo ramo para ele. Você já confirmou um monte de arquivos e todas essas confirmações estão no mestre. Felizmente, o GitLab
pode impedir o push'y diretamente no master. Portanto, podemos reverter todas as alterações necessárias para uma nova ramificação com os três comandos a seguir:
Nota : Certifique-se de confirmar ou esconder zeros primeiro suas alterações - caso contrário, todas serão perdidas! git branch future-brunch git reset HEAD~ --hard git checkout future-brunch
Uma nova ramificação será criada, no mestre - uma reversão é feita para o estado em que estava antes das alterações e, em seguida, é feita uma
verificação geral da nova ramificação com todas as suas alterações.
5. Opa ... Cometi um erro no nome do ramo
Os mais atentos puderam notar no exemplo anterior um erro no nome da ramificação. São quase três da tarde e eu ainda não jantei, então minha fome chamou o novo ramo (
br a nch ) de
futuro . Goodies!
Renomeie esta ramificação da mesma maneira que é usada ao renomear um arquivo usando o comando
mv , ou seja, colocando-o em um novo local com o nome correto:
git branch -m future-brunch feature-branch
Se você já envia este ramo por push, precisará de algumas etapas adicionais. Removeremos a ramificação antiga do
controle remoto e enviaremos a nova:
git push origin --delete future-brunch git push origin feature-branch
Nota perev. : Você ainda pode remover uma ramificação do controle remoto usando: git push origin :future-brunch
6. Opa ... eu fiz de novo!
O último comando no evento em que tudo deu errado. Quando você acumulou e lançou várias soluções com o Stack Overflow, depois das quais tudo no repositório se tornou ainda pior do que era no começo. Todos nós uma vez enfrentamos semelhante ...
git reflog mostra uma lista de todas as operações que você executou. Em seguida, ele permite que você use os recursos mágicos de viagem no tempo do Git, ou seja, retornar a qualquer momento do passado. Devo observar que esta é sua última esperança - você não deve recorrer a ela em casos simples. Então, para obter a lista, faça:
git reflog
Cada uma das nossas etapas está sob o olhar atento do Git. A execução da equipe no projeto acima produziu o seguinte:
3ff8691 (HEAD -> feature-branch) HEAD@{0}: Branch: renamed refs/heads/future-brunch to refs/heads/feature-branch 3ff8691 (HEAD -> feature-branch) HEAD@{2}: checkout: moving from master to future-brunch 2b7e508 (master) HEAD@{3}: reset: moving to HEAD~ 3ff8691 (HEAD -> feature-branch) HEAD@{4}: commit: Adds the client logo 2b7e508 (master) HEAD@{5}: reset: moving to HEAD~1 37a632d HEAD@{6}: commit: Adds the client logo to the project 2b7e508 (master) HEAD@{7}: reset: moving to HEAD 2b7e508 (master) HEAD@{8}: commit (amend): Added contributing info to the site dfa27a2 HEAD@{9}: reset: moving to HEAD dfa27a2 HEAD@{10}: commit (amend): Added contributing info to the site 700d0b5 HEAD@{11}: commit: Addded contributing info to the site efba795 HEAD@{12}: commit (initial): Initial commit
Preste atenção na coluna mais à esquerda - este é o índice. Se você deseja retornar a qualquer ponto do histórico, execute o seguinte comando, substituindo
{index} pelo valor apropriado (por exemplo,
dfa27a2 ):
git reset HEAD@{index}
Portanto, agora você tem seis maneiras de sair dos Gitfalls mais frequentes
(trocadilho: pitfall se traduz em "armadilha, erro" - aprox. Transl. ) .
Bônus do tradutor
Em primeiro lugar, um comentário valioso sobre tudo o que foi escrito acima (exceto o parágrafo 5). Lembre-se de que essas ações alteram o histórico de confirmações, portanto, devem ser executadas apenas se as alterações não tiverem sido enviadas para
remoto (push'nut). Caso contrário, o antigo commit incorreto já estará na ramificação
remota e você terá que executar
git pull (que fará a
mesclagem e, em seguida, tentar "limpar" o histórico levará a piores conseqüências)) ou
git push --force , que está repleto de perda de dados ao trabalhar com um ramo de várias pessoas ...
Agora - pequenas adições úteis de nossa experiência:
- Se você (acidentalmente ou não) alterou a ramificação e precisa retornar à anterior, a maneira mais rápida é usar o
git checkout - . - Se você acidentalmente adicionou um arquivo ao commit que não deveria ser adicionado lá, mas ainda não o fez, use o
git reset HEAD path/to/file . Uma situação semelhante é descrita no parágrafo 3, mas, na realidade, é mais ampla, porque refere-se a alterações desnecessárias no commit (não apenas no caso de um arquivo extra). - É uma boa prática não confirmar demais, usando a opção
-p ao adicionar um arquivo a uma confirmação ( git add -p ). Isso permite revisar cada alteração que entra no commit. Mas vale lembrar que ele não adiciona arquivos não rastreados ao commit - eles precisam ser adicionados sem esse parâmetro. - Várias boas recomendações (incluindo as mais complexas) podem ser encontradas no artigo de 2014 “ Tutorial do Git: 10 problemas comuns do Git e como corrigi-los ”. Em particular, observe o uso de
git revert e git rebase -i .
PS do tradutor
Leia também em nosso blog: