📄 El historial de nuestros commits deberían leerse como a un 📗libro, para eso tenemos que mejorar la estructura y los mensajes en general de nuestros commits.
🤔 Por Qué Estructurar Nuestros Commits 🤔
- Determinar automáticamente un aumento de versión semántica (según los tipos de confirmaciones realizadas).
- Comunicar la naturaleza de los cambios a los compañeros de equipo, el público y otras partes interesadas.
- Activación de procesos de compilación y publicación.
- Facilitar que las personas contribuyan a sus proyectos, al permitirles explorar un historial de confirmación más estructurado.
🧬 Estructura del Commit 🧬
<tipo>: <descripcion>
[(opcional) cuerpo]
🧩 Tipo
El tipo hace referencia a grandes rasgos sobre los cambios que se están guardando en ese commit. Por ejemplo, si las modificaciones que hicimos fueron relacionadas a agregar una nueva característica o función, usaríamos el tipo feat. A continuación te dejo una lista extensa pero clara de otros diferentes tipos así como cuándo utilizarlos.
- 🎉 tada: Comenzar un proyecto.
- 🚀 release: Deploy de cosas.
- 🔖new version: Etiqueta / versión de lanzamiento.
- ✨ feat: Nueva característica.
- ♻️ refactor: Refactorizar código.
- 🐛 fix: Arreglo de un bug.
- 🩹 patch: Solución simple para un problema no crítico.
- ⚡️perf: Mejorar el rendimiento.
- 🎨 style: Mejorar la estructura / formato del código (espacios en blanco, formato, comas faltantes, entre otros).
- 💄 ui: Agregar o actualizar la interfaz de usuario y los archivos de estilo.
- 🚸 ux: Mejorar la experiencia de usuario / usabilidad.
- 🔥 remove: Eliminar código o archivos.
- 🚧 construction: Trabajo en progreso.
- ➕ add: Agregar una dependencia.
- ⏫ upgrade: Actualizar dependencia.
- ⏬ downgrade: Degradar dependencia.
- ⏪ revert: Revertir cambios.
- ♿️ accessibility: Mejorar la accesibilidad.
- 🔀 merge: Fusionar ramas.
- ✅ test: Agregar o actualizar pruebas.
- 🔧 config: Agregar o actualizar archivos de configuración.
- 🔨 script: Agregar o actualizar scripts de desarrollo.
- ✏️ typos: Corregir errores tipográficos.
- 💬 test: Agregar o actualizar texto y literales.
- 🚚 resources: Mover o cambiar el nombre de los recursos (archivos).
- 🍱 assets: Agregar o actualizar assets (imágenes).
- 🙈 gitignore: Agregar o actualizar un archivo .gitignore.
- 📱 responsive: Trabajo en diseño responsive.
- ⚗️ experiment: Realizar experimentos.
- 📝 docs: Agregar o actualizar documentación.
- 💡 comments: Agregar o actualizar comentarios en el código fuente.
- 🔍️ seo: Mejorar SEO.
- 🌱 seeds: Agregar o actualizar archivos semilla (archivos seeds en APIs).
- 🤖 chore: Otros cambios que no modifican src o archivos de prueba.
- 👷 ci: Cambios en los archivos y scripts de configuración de CI.
- 🔒️ security: Solucionar problemas de seguridad.
- 🔐 secrets: Agregar o actualizar secretos (variables de entorno).
- 🚨 linter: Arreglar advertencias del compilador / linter.
- 🌐 internationalization: Internacionalización y localización.
- 👽️ alien: Actualizar código debido a cambios en la API externa.
- 🗃️ db: Realizar cambios relacionados con la base de datos.
- 🛡️ types: Agregar o actualizar tipos.
- 💫 animations: Agregar o actualizar animaciones y transiciones.
- 🛂 auth: Trabajar en código relacionado con autorización, roles y permisos.
- ⚰️ dead: Eliminar código muerto.
- 👔 business: Agregar o actualizar la lógica de negocios.
- 🦺 validation: Agregar o actualizar código relacionado con la validación.
- 💥 BREAKING CHANGE: Un commit que tiene un footer
BREAKING CHANGE:, o agrega un ! después del tipo/scope, introduce cambios grandes a la API (correlacionado con el Versionado Semántico MAJOR). Un BREAKING CHANGE puede ser parte de un commit de cualquier tipo.
🧾 Descripción
La descripción es un breve resumen de los cambios en el código entre 50 y 60 caracteres.
- Utilizar el presente imperativo: “agregar”, no “agregado”, tampoco “agregados”.
- No iniciar con mayúscula la primera letra.
- Sin punto (.) al final.
📃 Cuerpo
Puede proporcionarse un cuerpo de descripción más largo después de la descripción breve, que brinda información contextual adicional sobre los cambios en el código. El cuerpo debe comenzar una línea en blanco después de la descripción.
👀 Ejemplos 👀
Commit sin cuerpo
refactor: ♻️ modularizar estilos del formulario
Commit sin cuerpo
refactor: ♻️ modularizar estilos del formulario
separar los estilos del formulario a un archivo seperado para un código más modular y mantenible
🙋 Espero que esto les ayude a estructurar fácilmente sus commits, sus colegas se los agradecerán!
