Todos nós sabemos como fazer git add ., git commit e git push. Alguns de nós até deixamos nossas IDEs fazerem isso por nós. Mas será que isso é tudo?
O Git tem sido uma das minhas paixões por um bom tempo, e isso é devido ao quão flexível e poderoso ele pode ser, quando utilizado corretamente. Existem três pontos de interesse principais para mim sobre o Git, e eu quero te convidar a explorar estas áreas comigo hoje:
Experiência de desenvolvedor
Recuperando arquivos
Flexibilidade
Experiência de desenvolvedor
Este ponto é com certeza o mais simples, mas de maneira nenhuma é o menos importante. Mesmo que não estejamos falando de comandos da CLI, estes pontos definitivamente deveriam estar na sua mente quando estiver começando um projeto.
A maioria (se não todos) os provedores de repositórios Git (por exemplo Github, Gitlab, BitBucket) interpretam o arquivo README.md como a página inicial da documentação do seu projeto. E é crucial que o seu README esteja atualizado, e que ele seja tão simples que mesmo pessoas que não saibam programar consigam configurar o projeto nas suas máquinas.
Aqui está uma lista de perguntas que o seu README deve responder:
Do que se trata o projeto?
Existe algum link de documentação de negócios ou da API?
Qual é o status de build para cada ambiente?
Como eu posso acessar cada um dos ambientes?
Qual é a stack de desenvolvimento?
Como eu instalo as dependências do projeto?
Há alguma variável de ambiente que eu preciso configurar no meu computador?
Como eu rodo o projeto?
Como o código é deployado?
É um pipeline automático ou eu preciso rodar algum comando?
Como eu posso contribuir com o projeto?
Onde eu posso encontrar a lista de prioridades do projeto?
Onde eu posso reportar um bug?
Com quem eu posso falar quando eu tiver alguma dúvida?
O código é mergeado via Pull Request?
Se sim, quem é responsável por fazer o merge quando o PR for aprovado?
Mas por quê?
O motivo pelo qual você deveria se importar em fazer o seu README tão bom quanto possível é que isso vai levar o seu tempo de onboarding para o mínimo possível, independente do nível de senioridade do novo desenvolvedor. E ainda por cima, o README vai fazer com que o cara novo esteja pronto ainda mais rápido!
Por último, um bom README vai precisar de uma boa documentação de projeto, o que vai diminuir os silos de conhecimento no seu time.
Mensagens de commit
O segundo passo para uma boa experiência de desenvolvedor está relacionado com mensagens de commit. Pode ser extremamente frustrante e demorado quando você está tentando entender onde um bug foi inserido e tudo o que você tem nas mensagens de commit são mensagens sem sentido e não está claro onde uma tarefa termina e a outra começa.
Aqui estão algumas dicas:
O seu git deveria contar a história de como o projeto foi desenvolvido. Algumas pessoas usam o ID de um card Kanban como prefixo para o commit, e outros simplesmente escrevem uma bela e descritiva mensagem explicando as mudanças. No fim das contas, não tem um único jeito certo de fazer.
Existe, porém, um jeito errado de fazer. Eu sei, às vezes estamos frustrados e cansados, e fazemos mensagens de commit como "testando fix", "por favor funciona agora", "bla", "teste simples", etc. Contudo, não é assim que as mensagens de commit deveriam ser normalmente
Como regra de ouro, eu gosto de utilizar o padrão de mensagens de git do Tim Pope como guia para as minhas mensagens. Além disso, você pode dar uma olhada no comando git rebase --interactive quando você está achando que as suas mensagens estão bagunçadas demais ou quando você precisa transformar um monte de commits de teste em um único commit funcional.
Recuperando arquivos
Todos nós já estivemos lá: você manda um git checkout nas alterações que demoraram uma semana inteira pra fazer numa sexta-feira às 5 da tarde. Mas nunca mais! Existe uma chance de que você poderá recuperar os seus arquivos.
Que entre o seu príncipe num cavalo branco: git fsck.
O git fsck é responsável por escanear o seu projeto e encontrar qualquer arquivo "pendurado" que não são acessíveis por qualquer nó na árvore do git. O Git cria um blob pendurado no momento em que você roda um git add no seu arquivo. Este arquivo vai ser anexado à arvore do git uma vez que você rode o git commit, e então ele deixará de estar pendurado.
Então, se você rodou o git add no seu arquivo, e só depois deu o git checkout, você deveria conseguir ver o arquivo rodando este comando: git fsck --lost-found
Este comando vai retornar uma lista de todos os arquivos pendurados no projeto, deste jeito:
Uma vez que você tenha esta hash, você pode utilizar outro dos lindos comandos salva vidas do Git: git cat-file. Ele funciona igual ao comando cat no seu terminal (se você não sabe o que o comando cat faz, ele imprime o conteúdo de um dado arquivo), mas para qualquer blob (arquivo dentro do git) do git. A sintaxe é mais ou menos assim: git cat-file <tipo> <hash>.
Às vezes pode acontecer de você ter árvores inteiras penduradas ao invés de arquivos (quando você dá git checkout numa pasta, por exemplo). É pra isso que serve o parâmetro <tipo>. Mas já que você não consegue recuperar arquivos em massa, as árvores penduradas só serão úteis para te lembrar quais arquivos estavam dentro daquela pasta. A maioria das vezes, o seu parâmetro <tipo> será "blob".
Aqui está um exemplo do primeiro commit completo, uma nova alteração, um checkout, e recuperação de um arquivo:
Daqui você consegue imprimir o conteúdo do arquivo para um novo arquivo utilizando o terminal desta maneira: git cat-file blob "sua-hash" > "nome-do-arquivo-novo" (ou você pode simplesmente copiar e colar o conteúdo direto do terminal, funciona de qualquer jeito).
Eu sei, daqui pra frente é um pouco de trabalho manual dependendo de quantos arquivos você tinha perdido, mas na boa, pelo menos você não vai precisar pensar uma segunda vez em como você criou aquela lógica complicada. Além disso, não deveria levar mais que duas horas recuperando tudo, e você sempre pode criar um script de automação para recuperar uma lista de arquivos.
Flexibilidade
Por último, mas não menos importante, flexibilidade. Eu vou lidar com este tópico em duas partes: gravação e busca.
Busca
Em primeiro lugar, vamos lidar com a busca, já que este é o caso de uso mais comum. Imagine que existe um bug que você resolveu em uma branch que não será mergeada no código principal. Deletar a branch também vai deletar a conserto do bug, e você não pode criar uma nova branch a partir desta porque tem um monte de código que não poderá ser usado.
O que você faz? Deleta o branch e codifica o conserto do bug outra vez? Copia os arquivos do conserto para fora do projeto e depois substitui os arquivos quando mudar para outra branch?
Você não precisa disso. O git te dá uma ferramenta específica para cuidar de casos em que você só precisa de um único commit de uma branch. O nome é git cherry-pick.
Aqui está como usar:
Você pega a hash que identifica o commit que você deseja mover
Você troca para a branch onde o commit deveria ir
Você roda o comando: git cherry-pick <hash-do-commit>
Pronto! O commit agora está na outra branch, sem todo o trabalho de ficar embaralhando arquivos que poderiam sobrescrever qualquer código feito na branch nova. A correção será adicionada como uma simples mudança que foi commitada como qualquer código comum.
Gravação
Agora, até aqui tudo está muito legal, muito bonito, mas você não pode fazer toda esta busca e recuperação se ficar criando aqueles commits gigantes que criam três melhorias ao mesmo tempo. É aqui que entra a flexibilidade do Git na hora de criar commits.
Primeiro, um bom commit sempre deve deixar o projeto funcionando. Eu gosto de fazer isso mesmo em branches de melhorias, com a única excessão de quando você está pedindo a ajuda de alguém, mas depois você manda um git rebase pra unir tudo num único commit funcional(ver a seção de Experiência de Desenvolvedor).
O commit ideal deveria conter exatamente o que é necessário para que a melhoria ou a correção funcionarem. Nada a mais, nada a menos.
E você pode pensar: "E se eu tiver melhorias e correções em um único arquivo?"
Não se preocupe, meu amigo! O git também tem algo pra você! O comando é este: git add --patch. A flag --patch no seu bom e velho git add te permite adicionar apenas um pedaço do arquivo para o commit. Desse jeito, você pode criar um commit com a correção de bug, e outro commit para a sua melhoria.
Conclusão
Isso conclui o nosso tour de algumas das não tão conhecidas ferramentas do git. E essa é apenas a ponta do iceberg quando se trata de git. Eu estou aprendendo git até hoje. Como disse Donald Rumsfeld: "Existem conhecimentos conhecidos. São aquelas coisas que nós já sabemos que entendemos muito bem. Existem desconhecimentos conhecidos. Essas são as coisas que nós reconhecemos que não entendemos muito bem. Mas também existem desconhecimentos desconhecidos. Essas são as coisas que nós nem sabemos que existem."
Eu acredito que nós crescemos muito a partir das coisas que nós reconhecemos que não sabemos muito bem. Reconhecendo isso, você tem uma lista muito clara das coisas que você precisa fazer para que você cresça como um desenvolvedor. E eu espero ter adicionado Git nesta lista.
Você conhece outras ferramentas git que são super úteis? Adiciona elas aqui nos comentários!
Conhece algum amigo que poderia se beneficiar do artigo? Compartilha! Eu tenho certeza de que este artigo vai ser um ótimo ponto de partida.
Comments