18/08/2021 Compromissos Convencionais

VERSÕES LÍNGUAS CERCA DE

Compromissos
Convencionais
Uma especificação para adicionar significado legível por
humanos e por máquina para enviar mensagens

Resumo Rápido Especificação Completa Contribuir

Compromissos Convencionais
https://www.conventionalcommits.org/en/v1.0.0/ 1/9
 p
18/08/2021 Compromissos Convencionais

1.0.0
Resumo

A especificação Conventional Commits é uma convenção leve no

topo das mensagens de commit. Ele fornece um conjunto fácil
de regras para a criação de um histórico de commits
explícito; o que torna mais fácil escrever ferramentas
automatizadas. Esta convenção se encaixa com o SemVer ,
descrevendo os recursos, correções e alterações importantes
feitas nas mensagens de confirmação.

A mensagem de confirmação deve ser estruturada da seguinte

forma:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

O commit contém os seguintes elementos estruturais, para

comunicar a intenção aos consumidores de sua biblioteca:

1. correção: um commit do tipo corrige fix um bug em sua

base de código (isso se correlaciona com o PATCH Controle
de versão semântica).
2. talento: um commit do tipo feat introduz um novo
recurso para a base de código (isso se correlaciona com
o MINOR Versão Semântica).
3. QUEBRANDO ALTERAÇÃO: um commit que tem um rodapé BREAKING
CHANGE: , ou anexa um ! após o tipo / escopo, introduz uma
alteração de API de quebra (correlacionando com o

MAJOR Controle de Versão Semântico). A BREAKING CHANGE

pode ser parte de commits de qualquer tipo .
https://www.conventionalcommits.org/en/v1.0.0/ 2/9
18/08/2021 Compromissos Convencionais

4. tipos diferentes de fix: e feat: são permitidos, por

exemplo @ commitlint / configuração convencional (com
base no a convenção angular ) recomenda build: , chore: ,
ci: , docs: , style: , refactor: , perf: , test: , e outros.
5. outros rodapés que não BREAKING CHANGE: <description> podem ser
fornecidos e seguem uma convenção semelhante ao
formato
git trailer .

Tipos adicionais não são obrigatórios pela especificação

Convencional de Compromissos e não têm efeito implícito no
Controle de Versão Semântico (a menos que incluam uma
MUDANÇA QUEBRANTE).
Um escopo pode ser fornecido para um
tipo de confirmação, para fornecer informações contextuais
adicionais e está contido entre parênteses, por exemplo
feat(parser): add ability to parse arrays ,.

Exemplos

Mensagem de confirmação com descrição e rodapé de

alteração de quebra

feat: allow provided config object to extend other configs

BREAKING CHANGE: `extends` key in config file is now used for extending other config fil

Comprometa a mensagem ! para chamar a atenção para

mudanças significativas

refactor!: drop support for Node 6

Comprometa a mensagem com o escopo e ! chama a atenção

para mudanças importantes

refactor(runtime)!: drop support for Node 6

Mensagem de confirmação com ! rodapé de INTERRUPÇÃO DE

ALTERAÇÃO
https://www.conventionalcommits.org/en/v1.0.0/ 3/9
18/08/2021 Compromissos Convencionais

refactor!: drop support for Node 6

BREAKING CHANGE: refactor to use JavaScript features not available in Node 6.

Enviar mensagem sem corpo

docs: correct spelling of CHANGELOG

Confirme a mensagem com escopo

feat(lang): add polish language

Enviar mensagem com corpo de vários parágrafos e

vários rodapés

fix: correct minor typos in code

see the issue for details

on typos fixed.

Reviewed-by: Z

Refs #133

Especificação

As palavras-chave “DEVE”, “NÃO DEVE”, “OBRIGATÓRIO”, “DEVE”,

“NÃO DEVE”, “DEVE”, “NÃO DEVE”, “RECOMENDADO”, “PODE” e
“OPCIONAL” neste documento são deve ser interpretado
conforme descrito no RFC 2119 .

1. Submissões deve ser prefixado com um tipo, o qual

consiste de um substantivo, feat , fix , etc., seguido
pelo âmbito OPCIONAL, OPCIONAL ! , e cólon e do terminal
REQUERIDA espaço.
2. O tipo feat DEVE ser usado quando um commit adiciona um
novo recurso ao seu aplicativo ou biblioteca.

3. O tipo fix DEVE ser usado quando um commit representa

uma correção de bug para seu aplicativo.
https://www.conventionalcommits.org/en/v1.0.0/ 4/9
18/08/2021 Compromissos Convencionais

4. Um escopo PODE ser fornecido após um tipo. Um escopo

DEVE consistir em um substantivo que descreve uma seção
da base de código entre parênteses, por
exemplo, fix(parser):
5. Uma descrição DEVE seguir imediatamente os dois pontos e
o espaço após o prefixo de tipo / escopo. A descrição é
um breve resumo das alterações do código, por exemplo,
fix: problema de análise de array quando vários espaços
estavam contidos na string .
6. Um corpo de commit mais longo PODE ser fornecido após a
breve descrição, fornecendo informações contextuais
adicionais sobre as alterações do código. O corpo DEVE
começar uma linha em branco após a descrição.
7. Um corpo de commit é de forma livre e PODE consistir em
qualquer número de parágrafos separados por nova linha.
8. Um ou mais rodapés PODEM conter uma linha em branco após
o corpo. Cada rodapé DEVE consistir em um token de
palavra, seguido por um separador :<space> ou <space># ,
seguido por um valor de string (isso é inspirado na
convenção git trailer ).
9. Um token de rodapé DEVE ser usado - no lugar de
caracteres de espaço em branco, por exemplo, Acked-
by (isso ajuda a diferenciar a seção de rodapé de um corpo
de vários parágrafos). Uma exceção é feita para BREAKING
CHANGE , que PODE também ser usada como um token.
10. O valor de um rodapé PODE conter espaços e novas linhas,
e a análise DEVE terminar quando o próximo par válido de
token / separador de rodapé for observado.
11. Quebrando mudanças DEVEM ser indicadas no prefixo de
tipo / escopo de um commit, ou como uma entrada no
rodapé.
12. Se incluída como um rodapé, uma alteração de quebra DEVE
consistir no texto em maiúsculas QUEBRANDO ALTERAÇÃO,
seguido por dois pontos, espaço e uma descrição, por

exemplo,
QUEBRANDO ALTERAÇÃO: as variáveis ​
de ambiente
agora têm precedência sobre os arquivos de configuração .
https://www.conventionalcommits.org/en/v1.0.0/ / 5/9
18/08/2021 Compromissos Convencionais

13. Se incluídas no prefixo de tipo / escopo, as alterações

significativas DEVEM ser indicadas por um
! imediatamente antes de : . Se ! for usado, BREAKING
CHANGE: PODE ser omitido da seção de rodapé, e a descrição
do commit DEVERÁ ser usada para descrever a alteração
decisiva.
14. Tipos diferentes de feat e fix PODEM ser usados ​
em suas
mensagens de commit, por exemplo, docs: ref docs
atualizados.
15. As unidades de informação que compõem os Convencionais
Commits NÃO DEVEM ser tratadas com distinção entre
maiúsculas e minúsculas pelos implementadores, com
exceção de QUEBRAR ALTERAÇÃO, que DEVE ser maiúscula.
16. BREAKING-CHANGE DEVE ser sinônimo de BREAKING CHANGE,
quando usado como um token em um rodapé.

Por que usar compromissos convencionais

Gerando CHANGELOGs automaticamente.

Determinar automaticamente um aumento de versão
semântica (com base nos tipos de commits recebidos).
Comunicar a natureza das mudanças aos colegas de equipe,
ao público e a outras partes interessadas.
Acionando processos de construção e publicação.
Tornando mais fácil para as pessoas contribuírem com seus
projetos, permitindo que explorem um histórico de
commits mais estruturado.

Perguntas frequentes

Como devo lidar com mensagens de confirmação na fase

inicial de desenvolvimento?

Recomendamos que você proceda como se já tivesse lançado o

produto. Normalmente alguém , mesmo que sejam seus colegas

desenvolvedores de software, está usando o seu software.

Eles vão querer saber o que foi consertado, o que quebrou,
etc
https://www.conventionalcommits.org/en/v1.0.0/ 6/9
18/08/2021 Compromissos Convencionais
etc.

Os tipos no título do commit são maiúsculos ou

minúsculos?

Qualquer caixa pode ser usada, mas é melhor ser

consistente.

O que eu faço se o commit estiver em conformidade com

mais de um dos tipos de commit?

Volte e faça vários commits sempre que possível. Parte do

benefício dos compromissos convencionais é sua capacidade de
nos levar a fazer compromissos e RPs mais organizados.

Isso não desencoraja o desenvolvimento rápido e a

iteração rápida?

Desestimula o movimento rápido de forma desorganizada. Ele

ajuda você a se mover rapidamente a longo prazo em vários
projetos com contribuidores variados.

Os Convencional Commits podem levar os

desenvolvedores a limitar o tipo de commits que fazem
porque eles estarão pensando nos tipos fornecidos?

Os commits convencionais nos encorajam a fazer mais de

certos tipos de commits, como correções. Além disso, a
flexibilidade dos commits convencionais permite que sua
equipe crie seus próprios tipos e altere esses tipos ao
longo do tempo.

Como isso se relaciona com o SemVer?

fix commits de tipo devem ser traduzidos para

PATCH lançamentos. feat commits de tipo devem ser traduzidos
para MINOR lançamentos. Commits com BREAKING CHANGE nos commits,
independentemente do tipo, devem ser traduzidos para
MAJOR lançamentos.

Como devo criar uma versão de minhas extensões para a

especificação de commits convencionais, por exemplo
@jameswomack/conventional commit spec ?
https://www.conventionalcommits.org/en/v1.0.0/ 7/9
18/08/2021 Compromissos Convencionais
@jameswomack/conventional-commit-spec ?

Recomendamos o uso do SemVer para lançar suas próprias

extensões para esta especificação (e encorajamos você a
fazer essas extensões!)

O que eu faço se acidentalmente usar o tipo de

confirmação errado?

Quando você usa um tipo que é da especificação, mas não é o tipo

correto, por exemplo, em fix vez de feat

Antes de mesclar ou liberar o erro, recomendamos usar git

rebase -i para editar o histórico de commits. Após o
lançamento, a limpeza será diferente de acordo com as
ferramentas e processos usados.

Quando você usou um tipo 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 for

efetuado que não atenda à especificação de Convencionalmente
Compromissos. Significa simplesmente que o commit será
perdido por ferramentas baseadas nas especificações.

Todos os meus colaboradores precisam usar a

especificação Conventional Commits?

Não! Se você usar um fluxo de trabalho baseado em squash no

Git, os mantenedores líderes podem limpar as mensagens de
commit à medida que são mescladas - sem adicionar carga de
trabalho aos committers casuais. Um fluxo de trabalho comum
para isso é fazer com que seu sistema git reprima
automaticamente os commits de uma solicitação pull e
apresente um formulário para o mantenedor líder inserir a
mensagem git commit apropriada para a fusão.

Como os commits convencionais lidam com os commits de

reversão?

Reverter o código pode ser complicado: você está revertendo

vários commits? se você reverter um recurso, a próxima
versão deve ser m
https://www.conventionalcommits.org/en/v1.0.0/ tch? 8/9
18/08/2021 Compromissos Convencionais
versão deve ser um patch?

O Convencional Commits não faz um esforço explícito para

definir o comportamento de reversão. Em vez disso, deixamos
para os autores das ferramentas usar a flexibilidade dos
tipos e rodapés para desenvolver sua lógica para lidar com
reversões.

Uma recomendação é usar o revert tipo e um rodapé que faça

referência aos SHAs de confirmação que estão sendo
revertidos:

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868

Licença
Creative Commons - CC BY 3.0

https://www.conventionalcommits.org/en/v1.0.0/ 9/9