Nossos padrões de nomenclatura para branches e commits
O time pode trabalhar bem e produzir código de qualidade, ainda assim, os branches e commits podem ser uma bagunça generalizada se não existir um padrão definido que toda a equipe deve seguir.
Criar (ou adaptar) um padrão para os commits e branches não é trabalhoso e se feito no começo do projeto terá zero relutância da equipe, pois todos irão decidir juntos as normas seguidas.
Para os commits, além dos benefícios de legibilidade, padronizar as mensagens também permite gerar um changelog de mudanças entre versões de forma mais fácil, isso porque cada commit está categorizado.
O nosso padrão
Branches
Nomes de branches são compostos de 3 partes:
1 — type ou categoria do branch. Os types podem ser os seguintes:
- docs: apenas mudanças de documentação;
- feat: uma nova funcionalidade;
- fix: a correção de um bug;
- perf: mudança de código focada em melhorar performance;
- refactor: mudança de código que não adiciona uma funcionalidade e também não corrigi um bug;
- style: mudanças no código que não afetam seu significado (espaço em branco, formatação, ponto e vírgula, etc);
- test: adicionar ou corrigir testes.
2 — o que o branch faz em si.
3 — Código da tarefa no Jira. Ex.: PL-123.
Exemplos de alguns nomes de branches que podem existir em nossa aplicação:
- feat-cadastro-veiculos-PL-123
- refactor-edicao-colaboradores-PL-355
- fix-busca-checklists-PL-232
O código da tarefa no Jira é extremamente importante, ele ajuda autor e reviewer a localizarem o branch correto e também permite ao Jira linkar automaticamente um branch a uma tarefa, tornando o mesmo acessível a partir da tarefa:
Commits
O padrão usado aqui na Prolog App foi fortemente inspirado nos guidelines de commit do angular.
Essa é a estrutura que seguimos para um commit:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>Vamos dissecá-la:
1 — type ou categoria do commit: podem ser os mesmos utilizados para criar branches e que foram explicados acima.
2 — scope: onde a alteração foi feita. Aqui, criamos nossos próprios scopes que, na maioria dos casos, refletem o nome de uma funcionalidade.
3 — subject: um resumo do commit. Deve utilizar o imperativo, como: faz, adiciona, altera, muda e etc.
4 — body: espaço utilizado para detalhar o que foi feito. É opcional.
5 — footer: onde colocamos as PLs (códigos das tarefas no Jira) e também alguma breaking change.
Onde tem <BLANK LINE> significa que temos que deixar uma linha em branco. 🤷🏻♂️
Exemplo de um commit:
refactor(veículo): altera inserção da placa para utilizar trimPL-1234
Perceba que o exemplo acima não possui body.
Tão importante quanto definir um padrão, é deixar ele facilmente acessível ao time. Aqui, cada um tem o seu “cheat sheet” bem resumido e colá-lo ao monitor pode ser bem eficiente.
Aqui, nós começamos o projeto sem ter um padrão definido para os branches e commits. Porém, demos um grande salto em organização quando isso foi feito. Caso sua equipe não possua nada definido, nunca é tarde para começar.
Agora, se o seu time já segue algum padrão, conta pra gente como ele é. Assim podemos nos inspirar para seguir melhorando o nosso.
