From 44809279c7d43005c0cb119f521781d6c7438f31 Mon Sep 17 00:00:00 2001 From: Ivan Rosolen Date: Sun, 9 Jun 2019 23:36:31 -0300 Subject: [PATCH] feat(lang): add brazilian portuguese (pt-br) language (#157) --- config.yaml | 17 ++ content/v1.0.0-beta.4/index.pt-br.md | 259 +++++++++++++++++++++++++++ 2 files changed, 276 insertions(+) create mode 100644 content/v1.0.0-beta.4/index.pt-br.md diff --git a/config.yaml b/config.yaml index cdc9d96..9c6cdbe 100755 --- a/config.yaml +++ b/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 diff --git a/content/v1.0.0-beta.4/index.pt-br.md b/content/v1.0.0-beta.4/index.pt-br.md new file mode 100644 index 0000000..d724829 --- /dev/null +++ b/content/v1.0.0-beta.4/index.pt-br.md @@ -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: + +--- + +``` +[escopo opcional]: + +[corpo opcional] + +[rodapé opcional] +``` +--- + +
+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). +
+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. + +[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org) + +_quer seu projeto nesta lista?_ [envie um pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).