* Determinar automaticamente um aumento de versionamento semântico (com base nos
tipos de commits).
* Comunicar a natureza das mudanças para colegas de equipe, o público e outras
partes interessadas.
* Disparar processos de build e deploy.
* Facilitar a contribuição de outras pessoas em seus projetos, permitindo que
eles explorem um histórico de commits mais estruturado.
## Perguntas Frequentes
### Como devo lidar com mensagens de commit na fase inicial de desenvolvimento?
Recomendamos que você proceda como se já tivesse lançado o produto. Normalmente
*alguém*, mesmo que seja seus colegas desenvolvedores, está usando
seu software. Eles vão querer saber o que foi corrigido, o que quebra etc.
### Os tipos no título das mensagens commit são maiúsculos ou minúsculos?
Qualquer opção pode ser usada, mas é melhor ser consistente.
### O que eu faço se o commit estiver de acordo com mais de um dos tipos?
Volte e faça vários commits sempre que possível. Parte do benefício do Conventional
Commits é a capacidade de nos levar a fazer commits e PRs mais organizados.
### Isso não desencoraja o desenvolvimento rápido e a iteração rápida?
Desencoraja a movimentação rápida de forma desorganizada. Ele ajuda você a ser capaz de se mover rapidamente a longo prazo em vários projetos com vários colaboradores.
### O Conventional Commits leva os desenvolvedores a limitar o tipo de commits que eles fazem porque estarão pensando nos tipos fornecidos?
O Conventional Commits nos encorajam a fazer mais commits de tipos específicos, por exemplo correções. Além disso, a flexibilidade do Conventional Commits permite que sua equipe crie seus próprios tipos e altere ao longo do tempo.
### Qual a relação com o SemVer?
Commits do tipo `fix` devem ser enviados para releases `PATCH`. Commits do tipo
`feat` devem ser enviados para releases `MINOR`. Commits com `BREAKING CHANGE`
nas mensagens, independentemente do tipo, devem ser enviados para releases `MAJOR`.
### Como devo versionar minhas extensões utilizando a especificação do Conventional Commits Specification, e.g. `@jameswomack/conventional-commit-spec`?
Recomendamos utilizar o [SemVer](http://semver.org) para liberar suas próprias
extensões para esta especificação (e incentivamos você criar essas extensões!)
### O que eu faço se acidentalmente usar o tipo errado de commit?
#### Quando você usou um tipo da especificação, mas não do tipo correto, por exemplo `fix` em vez de `feat`
Antes do merge ou relase com o erro, recomendamos o uso de `git rebase -i` para
editar o histórico do commit. Após o release, a limpeza será diferente de
acordo com as ferramentas e processos que você utiliza.
#### Quando você usou um tipo que *não* é da especificação, por exemplo `feet` em vez de `feat`
Na pior das hipóteses, não é o fim do mundo se um commit não atender à
especificação do Conventional Commits. Significa apenas que o commit será
ignorado por ferramentas baseadas nessa especificação.
### Todos os meus colaboradores precisam usar a especificação do Conventional Commits?
Não! Se você usar um workflow de git baseado em squash, os mantenedores poderão
limpar as mensagens de commit à medida que forem fazendo novos merges, não
adicionando carga de trabalho aos committers casuais. Um workflow comum para
isso é fazer com que o git faça squash dos commits automaticamente de um pull
request e apresente um formulário para o mantenedor inserir a mensagem do commit
apropriada para o merge.
## Sobre
A especificação do Convencional Commits é inspirada e fortemente baseada na
