Como eu crio commits, branchs e PRs no Git
Eu postei esse artigo no meu blog pessoal, mas acho que ele é muito legal pra trazer aqui pra gente discutir.
Recentemente li um artigo da Annie Sexton chamado "Git Organized: A Better Git Flow" que me fez perceber que talvez seja legal compartilhar algumas regrinhas que sigo na hora de criar meus Pull Requests.
Gosto muito do princípio KISS (Keep It Simple, Stupid) e tento seguir isso em tudo que faço, desde os designs e até no código, inclusive a mesa de trabalho. Também gosto de seguir o karma "deixe tudo mais organizado do que encontrou", se vejo que tem algo que pode ser ajustado, eu sempre busco melhorar.
E, eu acredito, que uma das piores coisas que se pode acontecer quando você vai fazer um code review é encontrar uma PR sem contexto e, pior ainda, com alteração em vários arquivos. Por isso, busco sempre seguir essas 3 pequenas regras:
Codar e depois commitar
Eu sempre fiz isso, mas nunca achei que era algo certo, até ler o artigo citado acima. Eu costumo primeiro fazer o trabalho necessário, testar e depois selecionar os arquivos que possuem um contexto único e fazer um commit só com todos. Dessa forma eu possuo uma branch com menos commits e que eles claramente seguem uma sequencia.
No artigo, inclusive, possui uma dica legal onde ela sugere você continuar fazendo commits recorrentes (para não perder trabalho) e depois usar o git reset origin/main para ter sua branch limpa.
Usar os commits semânticos
Aprendi sobre eles faz pouco tempo, mas eles ajudam muito na hora até de saber o que escrever e dão um significado claro para a mensagem. Eu costumo usar somente alguns deles e sempre commitar em português.
- chore: quando adiciono arquivos que não são códigos ou quando adiciono alguma lib nova
- feat: o que mais uso, quando adiciono alguma feature
- fix: quando estou corrigindo algum erro
- refactor: quando estou refatorando
- test: quando adiciono testes
Separar uma PR grande em outras menores
Isso acredito ser algo muito importante para ter menos arquivos por PR. Digamos, por exemplo, que você vá criar um novo componente, um novo método ou um novo hook. Logo depois você provavelmente vai precisar substituir os lugares que usavam código legado, correto? Na maioria das vezes sim.
Você pode simplesmente criar uma PR somente com a criação do novo componente, novo método ou novo hook e outra PR onde apenas substitui os arquivos. Ou, quando você precisa adicionar uma nova biblioteca? Uma PR apenas para adicionar a biblioteca ou arquivos e outra em seguida para usá-la. Dessa forma, fica claro quando uma PR precisa de um code review mais "detalhado" e outra é apenas alteração de uma linha em vários arquivos, por exemplo.
Mantenha as coisas simples
Os benefícios de seguir essa prática são bons para você e também para seu time. Pense bem!