Git - Dicas rápidas pra uma boa gestão do seu código
Published: 2020-08-10 21:41:00

Nada como saber usar bem as ferramentas que você tem à sua mão, não é mesmo? 


Como disse Kent Becks:

> não precisamos ser programadores excepcionais, mas bons programadores com excelentes hábitos.


Tá, não deve ter sido exatamente isso que ele disse, mas você entendeu. 


1.  escolha um *padrão*  que você e seu time sigam. Pelo menos inicie de um e adapte de acordo com seu time e projeto. Dois bem conhecidos são o Git Flow e o Trunk Based Development. O primeiro é mais simples mas tem problemas ao escalar (filas de PRs). O segundo exige maturidade técnica e de qualidade, pois os commits são na master.


2. A partir de um padrão, recomendo colocar um sistema para rodar validações a cada commit ou push. Existe o husky para projetos baseados em NodeJS. Isso pois por mais que tenha carinho e atenção, a maior segurança vem dessas validações.


3. Outra coisa é: Leia o terminal! Olha o que a ferramenta ta te dizendo sobre como está seu repositório...ela vai te dar dicas valiosas. Vai te indicar a usar um comando ou outro dependendo do cenário. Leia o terminal!

![Imagem indicando mensagens do terminal, mostrando a importância de ler ele.](https://dev-to-uploads.s3.amazonaws.com/i/vwjul0rkd0yj1ena9665.png)



Abaixo os comandos que mais uso no meu dia a dia:




* `git status` -> pra ver o estado do seu repo local em comparação com o remoto (esse vcs já devem usar diariamente)

* `git add -p` -> pra ir vendo em pequenos pedaços (chunks) de código o diff do que foi mexido, e ir incluindo ou não. É uma forma interativa de criar o package do commit

* `git commit -m "mensagem padronizada"` -> cria o pacote a ser enviado ao repo remoto, recomendo padrão commit lint, é possível utilizar ferramentas pra analisar os commits

* `git stash`/`git stash pop` -> esse comando armazena as suas alterações em uma fila, e restaura o estado que estava na sua branch. Uso quando quero guardar o que estava fazendo rapidamente e ir pra outra branch, por exemplo. Mas também é viável e até mais recomendável commitar e depois usar ammend pra rescrever o commit WIP (Work in progress).

* `git commit --amend --no-edit` -> uso quando quero adicionar algo ao commit anterior sem editar a mensagem. Use com cuidado, exige um `git push -f` após

* `git rebase <BRANCH_NAME>` -> atualiza sua branch com outra, mas diferente do merge, pull ou fetch, que trazem as alterações acima da sua, o rebase reescreve a história da sua branch, removendo sua alteração, colocando a história da branch indicada no comando, e aí sim colocando seus commits novamente. Por isso quando você for resolver conflitos após este método você verá suas alterações como novas, e o código "antigo" na verdade já terá atualização do rebase. Também obriga o uso de `git push -f` após seu uso! Use com carinho.

* `git push` -> envia todas suas alterações para o repo remoto. 
* git revert <commit> -> esse comando remove certo commit do histórico. Muito útil quando um commit acabou quebrando algo, gerando um comportamento inexperado que os testes não pegaram, e você quer remover pra depois voltar corrigido.




Para resolver conflitos de Merge, recomendo uma interface como o VS Code. Facilita muito a vida!

Algumas dicas gerais seriam: Commits pequenos e constantes. Rebases constantes. Comunicação constante entre o time. O versionamento vai refletir o entrosamento (ou falta de) do time, assim como a organização das tarefas e sua granularidade.


Não adianta usar os melhores comandos mas ficar 2 semanas sem abrir a PR, gerando um distanciamento enorme entre as versões!


É isso! Valeu! :)