Skip to content

Padrões de uso do git

Nomeclatura dos commits

Todos as tarefas deverão estar escritas, em inglês, com todas as palavras em letras minúsculas, conforme padrão a seguir:

<scope> (<type>) : <subject>

Scopes:

  • Escopo se refere a parte de código que esta sofrendo modificações, e.x.: middleware, home, user-controller, entre outros.
  • Pode ser vazio, caso os arquivos modificações pertença a vários escopos, ou seja muito difícil delimitar um escopo.
  • Se você tiver de utilizar deste recurso provavelmente seu commit está pouco atômico, e poderia ter sido feito em pedaços menores.
  • Para monorepos utilize o escopo para definir o pacote, aplicação ou outro nível adequado.

Types:

Este atributo é obrigatório.

  • research: A research task about a technology or platform
  • build: Updates to the build process/scripts (eg: npm related/ adding external dependencies)
  • deploy: A deployment related task (eg: researching hosting platforms or adding code specific for a certain platform)
  • chore: A code change that external user won't see (eg: change to .gitignore file or .prettierrc file)
  • feat: A new feature
  • fix: A bug fix
  • docs: Documentation related changes
  • refactor: A code that neither fix bug nor adds a feature. (eg: You can use this when there is semantic changes like renaming a variable/ function name)
  • perf: A code that improves performance
  • style: A code that is related to styling
  • test: Adding new test or making changes to existing test
  • upgrade: Upgrade dependencies, packages (eg: upgrade strapi version)
  • wip: Use when work is in progress and you are aware that it will not be completed soon

Subjects:

Escreva suas mensagens de commit no imperativo: "Fix bug" e não "Fixed bug" ou "Fixes bug." Não use pontuação ao final. Não capitalize a primeira letra.

Description

Sempre que possível, complemente a mensagem do seu commit com uma descrição. Para adicionar uma descrição ao commit faça:

git commit -m "Subject" -m "Description"

A primeira opção -m é a mensagem do commit (subject), e a próxima opção -m é a descrição estendida.

Nomeclatura das branchs

  • main: Ela deve possuir o código estável da aplicação e estar pronta para a o ambiente de produção.

Os projetos podem ter essas branchs caso necessário:

  • develop: Ela deve ser a referência para os trabalhos em desenvolvimento. Aqui o código já deve ser funcional e ter sido revisado.
  • vX: Branch que segue a nomenclatura do semver com o prefixo "v". E.g.: v1.0.0. Deve ser usada em substituição a branch develop, com o intuito de trabalhar varias versões ao mesmo tempo.
  • stage: Branch para acionar o CI/CD e colocar o código em ambiente de homologação, que deve usar as mesmas tecnologias do ambiente de produção.
  • demo: Branch para acionar o CI/CD e colocar o código em ambiente de demonstração, que deve usar as mesmas tecnologias do ambiente de produção.

Além das branchs principais, podem existir outros grupos de branchs para apoiar o desenvolvimento. Esses grupos são:

  • feature: Criadas para o desenvolvimento de uma nova funcionalidade
  • hotfix: Criadas para uma correção rápida de erros nos ambientes de stage ou produção
  • experimental: Criadas para fazer experimentações com o código, devem ser temporárias.
  • bug: Criadas para a correção de erros e falhas
  • refactor: Criadas para refatorar código A criação de branchs dos grupos acima deve seguir o seguinte padrão:
<group>/<branch-objective>

Ex: feature/new-homepage e bug/remove-data-duplication

Os nomes das branchs também devem ser escritos em inglês e minúsculo. O grupo da branch deve ser a primeira palavra e após ela deve existir uma barra (/). Em seguida deve ser descrito em poucas palavras a nova feature ou o objetivo da branch. As palavras que compõem o objetivo deve ser separadas por hífem (-)

Fluxo dos merges e ordem de atualização

  • A branch main aceita merges da branch develop, vX e hotfix.
  • A branch develop e vX aceitam merges de branchs de features, bugs, refactors.
  • A branch stage aceita merges da vX. Ela é somente um gatilho para acionar o stage. Pode-se dar merge de features, refactors e bugs, se for necessário testar algo que ainda não está pronto para ir para a vX.
  • A branch demo aceita merges da vX.

A ordem de atualização das branchs é como abaixo, sendo main a menos atualizada subindo até a mais atualizada: - main < (demo e hotfix) < stage < (vX ou develop) < (bugs, refactors, features)

A ordem natural dos merges são da mais atualizada para a menos atualizada. Porem sempre que a camada de baixo sofre atualização as de cima devem se atualizar. e.x.: no caso de merge de hotfix na master, todas as demais devem ser atualizadas. E assim sucessivamente.

Merge requests

Utilizar template para merge requests, para facilitar a compreensão de quem for revisar, e lembrar quem está desenvolvendo de verificar se cobriu pontos importantes ao fazer modificações.

Tutorial de como criar e aplicar template de merge request:

  • https://docs.gitlab.com/ee/user/project/description_templates.html

Cada projeto tem um template diferente para atender as necessidades do projeto, esteja atento.

Veja exemplos de templates nos repositórios dos projetos: Planfy API, Planfy, Asset API.

Referências

  • https://dev.to/intrepid_ishan/git-commit-message-convention-that-you-can-follow-1709
  • https://docs.gitlab.com/ee/topics/gitlab_flow.html

Contribua

Este documento não é uma lei, e sim um acordo entre os devs de como iremos utilizar uma ferramenta que é de acesso comum, contribua fomentando a discussão e evolução deste documento.