diff --git a/config.yaml b/config.yaml index 8cbf992..5f98722 100755 --- a/config.yaml +++ b/config.yaml @@ -91,15 +91,16 @@ languages: weight: 2 languageName: "Spanish" title: Commits Convencionales - description: Una especificación que añade significado a los mensajes de commits para que sean legibles tanto por máquinas como por humanos + description: Especificación para dar significado a los mensajes de los commits haciéndolos legibles para máquinas y humanos actions: - label: Lee la especificación url: '#especificación' - label: GitHub url: 'https://github.com/conventional-commits/conventionalcommits.org' versions: - current: v1.0.0-beta.2 + current: v1.0.0-beta.3 list: + - v1.0.0-beta.3 - v1.0.0-beta.2 ru: diff --git a/content/v1.0.0-beta.2/index.es.md b/content/v1.0.0-beta.2/index.es.md index 9b3c6c3..63d4992 100644 --- a/content/v1.0.0-beta.2/index.es.md +++ b/content/v1.0.0-beta.2/index.es.md @@ -1,6 +1,5 @@ --- draft: false -aliases: ["/es/"] --- # Commits Convencionales 1.0.0-beta.2 diff --git a/content/v1.0.0-beta.3/index.es.md b/content/v1.0.0-beta.3/index.es.md new file mode 100644 index 0000000..61a4d3a --- /dev/null +++ b/content/v1.0.0-beta.3/index.es.md @@ -0,0 +1,237 @@ +--- +draft: false +aliases: ["/es/"] +--- + +# Commits Convencionales 1.0.0-beta.3 + +## Resumen + +La especificación de Commit Convencionales es una convención liviana que se aplica a los mensajes de los commits. +Esta especificación proporciona un conjunto fácil de reglas para crear un historial de commits explícito; +Esta convención se ajusta a [SemVer](http://semver.org), al describir las características, correcciones y cambios que rompen la compatibilidad en los mensajes de los commits. + +El mensaje del commit debe estar estructurado de la siguiente forma: + +--- + +``` +[ámbito opcional]: + +[cuerpo opcional] + +[nota de pie opcional] +``` + +--- + +
+El commit contiene los siguientes elementos estructurales para comunicar la +intención al consumidor de la librería: + +1. **fix:** un commit de _tipo_ `fix` corrige un error en la base del código + (se correlaciona con [`PATCH`](http://semver.org/#summary) en el versionado + semántico). +1. **feat:** un commit de _tipo_ `feat` introduce nuevas características en la + base del código (se correlaciona con [`MINOR`](http://semver.org/#summary) + en el versionado semántico). +1. **BREAKING CHANGE:** un commit que contiene el texto `BREAKING CHANGE:` al + inicio de su cuerpo opcional o la sección de nota de pie introduce un cambio + que rompe la compatibilidad en el uso de la API (se correlaciona con [`MAJOR`](http://semver.org/#summary) + en el versionado semántico). Un cambio en el uso de la API puede ser parte + de commits de _tipo_. e.g., a `fix:`, `feat:` & `chore:` todos tipos + válidos, adicional a cualquier otro _tipo_. +1. Otros: _tipos_ de commits distintos a `fix:` y `feat:` están permitidos, por + ejemplo [commitlint-config-conventional](https://github.com/marionebl/commitlint/tree/master/%40commitlint/config-conventional) + (basado en [the Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) + recomienda `chore:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:` y + otros. También recomendamos `improvement` para commits que mejorar una + implementación actual sin añadir nuevas características ni corregir errores. + Tenga presente que estos tipos no son impuestos por la especificación de + commits convencionales y no tienen efecto implícito en el versionado + semántico (a menos que incluyan el texto BREAKING CHANGE, lo cual NO es + recomendado). +
+ Se puede agregar un ámbito al _tipo_ de commit para proveer información + contextual adicional y se escribe entre paréntesis, e.g., `feat(parser): add ability to parse arrays`. + +## Ejemplos + +### Mensaje de commit con descripción y cambio que rompe la compatibilidad en el cuerpo + +``` +feat: allow provided config object to extend other configs + +BREAKING CHANGE: `extends` key in config file is now used for extending other config files +``` + +### Mensaje de commit sin cuerpo + +``` +docs: correct spelling of CHANGELOG +``` + +### Mensaje de commit con ámbito + +``` +feat(lang): added polish language +``` + +### Mensaje de commit para una corrección usando un número de problema (opcional) + +``` +fix: minor typos in code + +see the issue for details on the typos fixed + +fixes issue #12 +``` + +## Especificación + +Las palabras “DEBE” (“MUST”), “NO DEBE” (“MUST NOT”), “REQUIERE” (“REQUIRED”), +“DEBERÁ” (“SHALL”), “NO DEBERÁ” (“SHALL NOT”), “DEBERÍA” (“SHOULD”), +“NO DEBERÍA” (“SHOULD NOT”), “RECOMIENDA” (“RECOMMENDED”), “PUEDE” (“MAY”) Y +“OPCIONAL” (“OPTIONAL”) en este documento se deben interpretar como se describe +en [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt). + +1. Los commits DEBEN iniciarse con un tipo que consiste en un sustantivo `feat`, `fix`, etc., seguido de dos puntos y un espacio. +1. El tipo `feat` DEBE ser usado cuando un commit agrega una nueva + característica a la aplicación o librería. +1. El tipo `fix` DEBE ser usado cuando el commit representa una corrección a un + error en el código de la aplicación. +1. Se PUEDE añadir un ámbito opcional después del tipo. El ámbito es una frase + que describe una sección de la base del código encerrada en paréntesis, + e.g., `fix(parser):` +1. Una descripción DEBE ir inmediatamente después del tipo/ámbito inicial y es + una descripción corta de los cambios realizados en el código, e.g., + _fix: array parsing issue when multiple spaces were contained in string._ +1. Un cuerpo del commit más extenso PUEDE agregarse después de la descripción, + dando información contextual adicional acerca de los cambios en el código. + El cuerpo DEBE iniciar con una línea en blanco después de la descripción. +1. Una nota de pie PUEDE agregarse tras una línea en blanco después del + cuerpo o después de la descripción en caso de que no se haya dado un cuerpo. + La nota de pie DEBE contener referencias adicionales a los números de + problemas registrados sobre el cambio del código (como el número de problema + que corrige, e.g.,`Fixes #13`). +1. Los cambios que rompen la compatibilidad con la API DEBEN ser indicados al inicio de la nota de pie o el cuerpo del commit. Un cambio que rompe la compatibilidad con la API DEBE contener el texto en mayúsculas `BREAKING CHANGE`, seguido de dos puntos y espacio. +1. Una descripción se DEBE proveer después de `BREAKING CHANGE:`, describiendo + qué ha cambiado en la API, e.g., _BREAKING CHANGE: environment variables now take precedence over config files._ +1. La nota de pie DEBE contener solamente el texto `BREAKING CHANGE`, vínculos + externos, referencias a problemas u otra metainformación. +1. Otros tipos distintos a `feat` y `fix` PUEDEN ser usados en los mensajes de + los commits. + +## ¿Por qué usar Commits Convencionales? + +* Generación automática de CHANGELOGs. +* Determinación automática de los cambios de versión (basado en los tipos de + commits). +* Comunicar la naturaleza de los cambios a los demás integrantes del equipo, el + público o cualquier otro interesado. +* Ejecutar procesos de ejecución y publicación. +* Hacer más fácil a otras personas contribuir al proyecto, permitiendo explorar + una historia de los commits más estructurada. + +## FAQ + +### ¿Cómo puedo trabajar con los mensajes de los commits en la etapa inicial de desarrollo? + +Recomendamos trabajar como si ya hubiera lanzado su producto. Típicamente +_alguien_, incluso si son sus compañeros desarrolladores, están usando su +producto. Ellos querrán saber qué se ha arreglado, qué se ha dañado, etc. + +### ¿Se deben escribir los tipos de los commits en mayúscula o minúscula? + +Cualquiera está bien, pero es mejor ser consistente. + +### ¿Qué debo hacer si un commit encaja en más de un tipo de commit? + +Regrese y haga múltiples commits de ser posible. Parte de los beneficios de los +Commits Convencionales es la habilidad para hacer commits más organizados y así +mismo PRs. + +### ¿No desalienta esto el desarrollo y la iteración rápida? + +Desalienta moverse rápido de una forma desorganizada. Ayuda a moverse rápido a +largo plazo a través de proyectos con una gran variedad de contribuidores. + +### ¿Pueden los Commits Convencionales llevar a los desarrolladores a limitar el tipo de commits que hacen ya que estarán pensando en los tipos previstos? + +Los Commits Convencionales nos animan a hacer más de cierto tipo de commits como +_fixes_. Adicionalmente, la flexibilidad de los Commits Convencionales permite +a su equipo generar sus propios tipos y cambiarlos a lo largo del tiempo. + +### ¿Cómo se relaciona esto con SemVer? + +El tipo de commit `fix` se traduce a un cambio de versión `PATCH`. El tipo de +commit `feat` se traduce a un cambio de versión `MINOR`. Commits con el texto +`BREAKING CHANGE`, sin importar su tipo, se traducen a un cambio de versión +`MAJOR`. + +### ¿Cómo puedo versionar mis extensiones a la especificación de Commits Convencionales, e.g. `@jameswomack/conventional-commit-spec`? + +Recomendamos usar SemVer para liberar su propia extensión a esta especificación +(¡y lo animamos a hacer esta extensión!) + +### ¿Qué debo hacer si por accidente uso un tipo de commit equivocado? + +#### Cuando utiliza un tipo que es de la especificación pero no es el correcto, e.g. `fix` en lugar de `feat` + +Antes de combinar o liberar el error, recomendamos usar `git rebase -i` para +editar el historial de los commits. Después de que se ha liberado, la limpieza +será distinta de acuerdo con las herramientas y procesos que usted use. + +#### Cuando se usa un tipo que no está en la especificación, e.g. `feet` instead of `feat` + +En el peor de los escenarios, no es el fin del mundo si aparece un commit que no +cumple con las especificaciones de los commits convencionales. Simplemente, el +commit será ignorado por las herramientas que se basen en esta especificación. + +### ¿Deben todos los que contribuyen a mi proyecto usar esta especificación? + +¡No! Si usa un flujo de trabajo basado en `squash` los líderes del proyecto +pueden limpiar el mensaje en el momento en que se incorpora, sin agregar cargas +adicionales a quienes contribuyen casualmente. Un flujo de trabajo común para +esto es configurar su sistema de git para que haga el `squash` de manera +automática de un pull request y presente al líder del proyecto un formulario +para que ingrese el mensaje de commit correcto al momento de hacer el merge. + +## Acerca de + +La especificación de Commits Convencionales está inspirada, y fuertemente +basada, en [Angular Commit Guidelines](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines). + +El primer borrador de esta especificación ha sido escrito en colaboración con +algunos de los colaboradores de: + +* [conventional-changelog](https://github.com/conventional-changelog/conventional-changelog): + una serie de herramientas para analizar los mensajes de los commits de los + historiales de git. +* [bumped](https://bumped.github.io): una herramienta para liberar software que facilita realizar acciones antes y después de lanzar una nueva versión de su software. +* [unleash](https://github.com/netflix/unleash): una herramienta para + automatizar la liberación de software y ciclo de vida de publicación. +* [lerna](https://github.com/lerna/lerna): una herramienta para manejar + mono-repositorios, que creció a partir del proyecto Babel. + +## Herramientas para Commit Convencionales + +* [php-commitizen](https://github.com/damianopetrungaro/php-commitizen): una desarrollada para crear mensajes de confirmación según las especificaciones de Commits Convencionales. + Configurable y usable en proyectos de PHP como una dependencia de composer o utilizable globalmente para proyectos no PHP. +* [conform](https://github.com/autonomy/conform): una herramienta que se puede utilizar para aplicar políticas en los repositorios de git, incluidos los Commits Convencionales. + +## Proyectos usando Commits Convencionales + +* [yargs](https://github.com/yargs/yargs): el analizador de argumentos de la línea de comandos preferido por todos. +* [istanbuljs](https://github.com/istanbuljs/istanbuljs): una colección de herramientas y librerías de código abierto para agregar cobertura de código a sus tests. +* [standard-version](https://github.com/conventional-changelog/standard-version): versionado automático y manejos de CHANGELOG, usando el botón de squash de GitHub y siguiendo el flujo de trabajo de los Commits Convencionales. +* [uPortal-home](https://github.com/UW-Madison-DoIT/angularjs-portal) y [uPortal-application-framework](https://github.com/UW-Madison-DoIT/uw-frame): mejoramiento opcional para la interfaz de usuario [Apereo uPortal](https://www.apereo.org/projects/uportal). +* [massive.js](https://github.com/dmfay/massive-js): una librería para el acceso a datos para Node y PostgreSQL +* [electron](https://github.com/electron/electron): Construya aplicaciones multi-plataforma con JavaScript, HTML y CSS. +* [scroll-utility](https://github.com/LeDDGroup/scroll-utility): Un paquete de utilidades de desplazamiento fácil de usar para centrar elementos y realizar animaciones +* [Blaze UI](https://github.com/BlazeUI/blaze): Kit de herramientas modular de código abierto sin frameworks. +* [Monica](https://github.com/monicahq/monica): Un sistema de gestión de relaciones personales de código abierto. + +[![Conventional Commits](https://img.shields.io/badge/Conventional%20Commits-1.0.0-yellow.svg)](https://conventionalcommits.org) + +_¿Quiere ver su proyecto en esta lista?_ [haga un pull request](https://github.com/conventional-changelog/conventionalcommits.org/pulls).