mirror of
https://github.com/conventional-commits/conventionalcommits.org.git
synced 2024-11-15 02:45:15 +01:00
feat(lang): add brazilian portuguese (pt-br) language (#157)
This commit is contained in:
Ivan Rosolen
Benjamin E. Coe
parent
584fd571fd
commit
44809279c7
17
config.yaml
17
config.yaml
@ -170,3 +170,20 @@ languages:
|
||||
current: v1.0.0-beta.4
|
||||
list:
|
||||
- v1.0.0-beta.4
|
||||
|
||||
pt-br:
|
||||
weight: 2
|
||||
languageName: "Português Brasileiro"
|
||||
title: Conventional Commits
|
||||
description: Uma especificação para dar um significado legível as mensagens de commit para humanos e maquinas
|
||||
actions:
|
||||
- label: Resumo
|
||||
url: '#summary'
|
||||
- label: Especificação Completa
|
||||
url: '#specification'
|
||||
- label: GitHub
|
||||
url: 'https://github.com/conventional-commits/conventionalcommits.org'
|
||||
versions:
|
||||
current: v1.0.0-beta.4
|
||||
list:
|
||||
- v1.0.0-beta.4
|
||||
|
||||
259
content/v1.0.0-beta.4/index.pt-br.md
Normal file
259
content/v1.0.0-beta.4/index.pt-br.md
Normal file
@ -0,0 +1,259 @@
|
||||
---
|
||||
draft: false
|
||||
aliases: ["/pt-br/"]
|
||||
---
|
||||
|
||||
# Conventional Commits 1.0.0-beta.4
|
||||
|
||||
## Resumo
|
||||
|
||||
A especificação do Conventional Commits é uma convenção simples para utilizar nas
|
||||
mensagens de commit.
|
||||
Ela define um conjunto de regras para criar um histórico de commit
|
||||
explícito, o que facilita a criação de ferramentas automatizadas.
|
||||
Esta convenção segue o [SemVer](http://semver.org),
|
||||
descrevendo os recursos, correções e modificações que quebram a compatibilidade
|
||||
nas mensagens de commit.
|
||||
|
||||
A mensagem do commit deve ser estruturada da seguinte forma:
|
||||
|
||||
---
|
||||
|
||||
```
|
||||
<tipo>[escopo opcional]: <descrição>
|
||||
|
||||
[corpo opcional]
|
||||
|
||||
[rodapé opcional]
|
||||
```
|
||||
---
|
||||
|
||||
<br />
|
||||
O commit contém os seguintes elementos estruturais, para comunicar a intenção ao
|
||||
utilizador da sua biblioteca:
|
||||
|
||||
1. **fix:** um commit do _tipo_ `fix` soluciona um problema na sua base de código
|
||||
(isso se correlaciona com [`PATCH`](http://semver.org/#summary) do versionamento semântico).
|
||||
1. **feat:** um commit do _tipo_ `feat` inclui um novo recurso na sua base
|
||||
de código (isso se correlaciona com [`MINOR`](http://semver.org/#summary) do versionamento semântico).
|
||||
1. **BREAKING CHANGE:** um commit que contém o texto `BREAKING CHANGE:`, no começo
|
||||
do texto do corpo opcional ou do rodapé opcional, inclui uma modificação que quebra
|
||||
a compatibilidade da API (isso se correlaciona com [`MAJOR`](http://semver.org/#summary)
|
||||
do versionamento semântico). Uma BREAKING CHANGE pode fazer parte de commits de qualquer _tipo_.
|
||||
1. Outros: _tipos_ adicionais são permitidos além de `fix:` e `feat:`, por exemplo
|
||||
[@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional)
|
||||
(baseado na [Convenção do Angular](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines))
|
||||
recomenda-se `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, entre outros.
|
||||
|
||||
Também recomendamos `improvement` para commits que melhoram uma implementação
|
||||
atual sem adicionar um novo recurso ou consertar um bug.
|
||||
Observe que esses tipos não são obrigatórios pela especificação do Conventional
|
||||
Commits e não têm efeito implícito no versionamento semântico (a menos que incluam
|
||||
uma BREAKING CHANGE).
|
||||
<br />
|
||||
Um escopo pode ser adicionado ao tipo do commit, para fornecer informações
|
||||
contextuais adicionais e está contido entre parênteses, por exemplo
|
||||
`feat(parser): adiciona capacidade de interpretar arrays`.
|
||||
|
||||
## Exemplos
|
||||
|
||||
### Mensagem de commit com descrição e modificação que quebra a compatibilidade no corpo
|
||||
```
|
||||
feat: permitir que o objeto de configuração fornecido estenda outras configurações
|
||||
|
||||
BREAKING CHANGE: a chave `extends`, no arquivo de configuração, agora é utilizada
|
||||
para estender outro arquivo de configuração
|
||||
```
|
||||
|
||||
### Mensagem de commit com `!` opcional para chamar a atenção para quebra a compatibilidade
|
||||
```
|
||||
chore!: remove Node 6 da matriz de testes
|
||||
|
||||
BREAKING CHANGE: removendo Node 6 que atinge o final de vida em Abril
|
||||
```
|
||||
|
||||
### Mensagem de commit sem corpo
|
||||
```
|
||||
docs: ortografia correta de CHANGELOG
|
||||
```
|
||||
|
||||
### Mensagem de commit com escopo
|
||||
```
|
||||
feat(lang): adiciona tradução para português brasileiro
|
||||
```
|
||||
|
||||
### Mensagem de commit de uma correção utilizando número de ticket (opcional)
|
||||
```
|
||||
fix: corrige pequenos erros de digitação no código
|
||||
|
||||
veja o ticket para detalhes sobre os erros de digitação corrigidos
|
||||
|
||||
closes issue #12
|
||||
```
|
||||
|
||||
## Especificação
|
||||
|
||||
As palavras-chaves “DEVE” (“MUST”), “NÃO DEVE” (“MUST NOT”), “OBRIGATÓRIO” (“REQUIRED”),
|
||||
“DEVERÁ” (“SHALL”), “NÃO DEVERÁ” (“SHALL NOT”), “PODEM” (“SHOULD), “NÃO PODEM” (“SHOULD NOT”),
|
||||
“RECOMENDADO” (“RECOMMENDED”), “PODE” (“MAY”) e “OPCIONAL” (“OPTIONAL”), nesse
|
||||
documento, devem ser interpretados como descrito na [RFC 2119](http://tools.ietf.org/html/rfc2119).
|
||||
|
||||
1. A mensagem de commit DEVE ser prefixado com um tipo, que consiste em um
|
||||
substantivo, `feat`,` fix`, etc., seguido por um escopo OPCIONAL, e OBRIGATÓRIO
|
||||
terminar com dois-pontos e um espaço.
|
||||
1. O tipo `feat` DEVE ser usado quando um commit adiciona um novo recurso ao seu
|
||||
aplicativo ou biblioteca.
|
||||
1. O tipo `fix` DEVE ser usado quando um commit representa a correção de um
|
||||
problema em seu aplicativo ou biblioteca.
|
||||
1. 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): `
|
||||
1. Uma descrição DEVE existir depois do espaço após o prefixo tipo/escopo.
|
||||
A descrição é um breve resumo das alterações de código, por exemplo,
|
||||
_fix: problema na interpretação do array quando uma string tem vários espaços._
|
||||
1. Um corpo de mensagem de commit mais longo PODE ser fornecido após a descrição
|
||||
curta, fornecendo informações contextuais adicionais sobre as alterações no código.
|
||||
O corpo DEVE começar depois de uma linha em branco após a descrição.
|
||||
1. Um rodapé de uma ou mais linhas PODE ser fornecido depois de uma linha em branco
|
||||
após o corpo. O rodapé DEVE conter informações adicionais sobre o commit, por exemplo,
|
||||
pull-requests, revisores, modificações que quebram a compatibilidade, com uma
|
||||
informação adicional por linha.
|
||||
1. A modificação que quebra a compatibilidade DEVE ser indicadas logo no início
|
||||
da seção do corpo ou no início de uma linha na seção de rodapé. Uma modificação
|
||||
que quebra a compatibilidade DEVE consistir de um texto em maiúsculas
|
||||
BREAKING CHANGE, seguido por dois-pontos e um espaço.
|
||||
1. Uma descrição DEVE ser fornecida após o texto "BREAKING CHANGE:", descrevendo
|
||||
o que mudou na API, por exemplo, _BREAKING CHANGE: as variáveis de ambiente agora
|
||||
têm preferência sobre os arquivos de configuração._
|
||||
1. Além de `feat` e `fix`, outro tipo PODE ser usados em suas mensagens de commit.
|
||||
1. Cada bloco de informação que compõem o commit convencional NÃO DEVE ser
|
||||
tratado como sensível a maiúscula e minúscula pelos implementadores, com exceção de
|
||||
BREAKING CHANGE, que DEVE ser maiúscula.
|
||||
1. Um `!` PODE ser acrescentado antes do `:` no prefixo tipo/escopo, para chamar
|
||||
a atenção para modificações que quebram a compatibilidade. `BREAKING CHANGE: description`
|
||||
também DEVE ser incluído no corpo ou no rodapé, junto com o `!` no prefixo.
|
||||
|
||||
## Porque User Conventional Commits
|
||||
|
||||
* Criação automatizada de CHANGELOGs.
|
||||
* 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
|
||||
[Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines).
|
||||
|
||||
O primeiro rascunho desta especificação foi escrito em colaboração com algumas
|
||||
pessoas que contribuem para:
|
||||
|
||||
* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog):
|
||||
um conjunto de ferramentas para analisar mensagens de commit a partir do histórico git.
|
||||
* [bumped](https://bumped.github.io): uma ferramenta que facilita o "release" de
|
||||
software. Facilitando executar ações antes e depois de uma liberar uma nova versão.
|
||||
* [unleash](https://github.com/netflix/unleash): uma ferramenta para automatizar
|
||||
o ciclo de "release" e publicação de software.
|
||||
* [lerna](https://github.com/lerna/lerna): uma ferramenta para gerenciar monorepos,
|
||||
que surgiu do projeto Babel.
|
||||
|
||||
## Ferramentas para Conventional Commits
|
||||
|
||||
* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): uma
|
||||
ferramenta para criar mensagens de commit seguindo as especificações do
|
||||
Conventional Commits. Configurável e util para projetos PHP como dependência do
|
||||
composer ou "global" para projetos não-PHP.
|
||||
* [conform](https://github.com/autonomy/conform): uma ferramenta que pode ser
|
||||
usada para garantir "regras" em repositórios git, incluindo o Conventional Commits.
|
||||
* [standard-version](https://github.com/conventional-changelog/standard-version):
|
||||
Geração automática de versões e gerenciamento de CHANGELOG, usando o novo botão
|
||||
de squash do GitHub e o workflow recomendado do Conventional Commits.
|
||||
|
||||
## Projetos Utilizando Conventional Commits
|
||||
|
||||
* [yargs](https://github.com/yargs/yargs): o parser de argumentos de linha de
|
||||
comando, com tema de pirata, favorito de todos.
|
||||
* [istanbuljs](https://github.com/istanbuljs/istanbuljs): uma coleção de ferramentas
|
||||
e bibliotecas de código aberto para adicionar cobertura de teste a seus testes
|
||||
de JavaScript.
|
||||
* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) e
|
||||
[uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame):
|
||||
Aperfeiçoamento opcional da interface do usuário [Apereo uPortal](https://www.apereo.org/projects/uportal).
|
||||
* [massive.js](https://github.com/dmfay/massive-js): Uma biblioteca de acesso a
|
||||
dados para o Node e PostgreSQL.
|
||||
* [electron](https://github.com/electron/electron): Crie aplicativos desktop
|
||||
cross-platform com JavaScript, HTML e CSS.
|
||||
* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): Um pacote
|
||||
simples de usar para centralizar elementos e animações suaves.
|
||||
* [Blaze UI](https://github.com/BlazeUI/blaze): UI Toolkit de código aberto, Framework-free.
|
||||
* [Monica](https://github.com/monicahq/monica): Um CRM pessoal. Lembre-se de
|
||||
tudo sobre seus amigos e familiares.
|
||||
* [mhy](https://mhy.js.org): 🧩 Uma toolbox e sistema para desenvolvimento com
|
||||
zero configuração, pronta para uso, multifuncional.
|
||||
|
||||
[](https://conventionalcommits.org)
|
||||
|
||||
_quer seu projeto nesta lista?_ [envie um pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).
|
||||
Loading…
Reference in New Issue
Block a user