1. Introducción
Este documento establece los lineamientos para la creación de commits en nuestros proyectos de desarrollo. Un commit bien estructurado facilita la revisión de código, mejora la trazabilidad y mantiene un historial claro del proyecto.
Principio Fundamental: Commits Atómicos
Cada commit debe representar un único cambio lógico en el código. No combines múltiples funcionalidades o correcciones no relacionadas en un solo commit. Esta práctica facilita:
- Revisión de código más eficiente
- Facilidad para revertir cambios específicos
- Mejor trazabilidad del historial
- Integración continua más confiable
❌ Lo que NO debes hacer:
feat: implementar módulo completo de inutilización de guías
- Crear formulario de ingreso
- Agregar validaciones
- Implementar proceso de aprobación
- Crear reportes
- Actualizar dashboard
- Corregir bugs de interfazEste commit mezcla múltiples cambios que deberían estar separados.
✅ La forma correcta:
Dividir en commits atómicos:
feat(inventory): crear formulario de inutilización de guías
feat(inventory): implementar validaciones de formulario
feat(inventory): agregar flujo de aprobación
feat(inventory): integrar generación de reportes
feat(inventory): añadir widgets en dashboard
fix(inventory): corregir alineación de elementos en móviles2. Estructura del Mensaje
tipo(alcance): descripción
[cuerpo opcional]
[nota de pie opcional]Reglas de Formato
- Use "/" para indicar jerarquías en el alcance (ej:
puntoventa/pago) - No use guiones (-) en el alcance
- No deje espacios entre el tipo y los paréntesis del alcance
- Use minúsculas para el tipo y alcance
- La descripción debe comenzar con mayúscula
- Use siempre
feat(nofeature) para nuevas características
Nota Importante sobre Tipos de Commit
Los tipos de commit están estandarizados para mantener la consistencia y permitir la automatización. Por ejemplo, usamos feat en lugar de feature, fix en lugar de
bugfix, etc. Esto facilita la generación automática de changelogs y el mantenimiento del historial de cambios.
2.1 Tipos de Commit
Nuevas características o funcionalidades
Corrección de errores
Cambios en documentación
Cambios de formato, espaciado, etc.
Refactorización del código
Adición o modificación de tests
3. Ejemplos
Feature: Nuevo Proceso en ERP
feat(inventory): agregar proceso de inutilización de guías de remisión
- Implementar formulario de inutilización
- Crear validaciones de estado de guía
- Agregar registro de auditoría
- Actualizar menú de navegación en módulo de inventario
Resolves: #789
Área: Módulo de Inventario
Impacto: Permite gestionar guías no utilizadas según normativaFeature: Componente Específico
feat(inventory/shipment): crear tabla de guías inutilizadas
- Añadir columnas de fecha, motivo y usuario
- Implementar paginación y filtros
- Agregar acciones de exportación
- Integrar con API de consulta
Related to: #790
Component: RemissionGuideTableFix: Corrección en Proceso
fix(inventory/shipment): corregir validación de guías duplicadas
Se corrigió la validación que permitía inutilizar una guía
más de una vez. Se agregó verificación en base de datos y
mensajes de error apropiados.
Fixes: #791
Impacto: Crítico - Afecta integridad de datosRefactor: Diseño Responsive
refactor(pos/ui): adaptar diseño para dispositivos móviles
- Implementar diseño responsive en componente principal
- Ajustar grid de productos para tablets y móviles
- Optimizar menú lateral para vista móvil
- Rediseñar modal de pago para pantallas pequeñas
Devices: Tablets (768px-1024px), Smartphones (<768px)
Testing: Realizado en iOS y Android
Related to: #892 - Mejoras UX en POSRefactor: Optimización de Componentes
refactor(pos/components): optimizar rendimiento en dispositivos móviles
- Implementar lazy loading para catálogo de productos
- Reducir tamaño de imágenes para vista móvil
- Optimizar eventos touch y gestos
- Mejorar tiempo de carga inicial
Performance: Bundle size reducido en 45%
Memory Usage: Reducido de 180MB a 95MB en móviles
Related Components: ProductGrid, PaymentModal, SideMenuStyle: Ajustes CSS
style(pos): implementar media queries y flexbox
- Agregar breakpoints para diferentes dispositivos
- Convertir tablas a diseño flexible
- Ajustar tamaños de fuente y espaciado
- Implementar grid system responsive
CSS Framework: Tailwind
Breakpoints: sm(640px), md(768px), lg(1024px)
Files Modified: pos.css, components/*.cssDocs: Actualización de Documentación
docs(inventory): actualizar documentación de inutilización de guías
- Agregar diagramas de flujo del proceso
- Incluir ejemplos de casos de uso
- Actualizar manual de usuario
- Documentar APIs relacionadas
Type: Technical Documentation
Ubicación: /docs/inventory/shipment-guides/4. Buenas Prácticas
Principio de Commits Atómicos
❌ Commit No Atómico:
Mezclando múltiples cambios:
feat(pos): actualizar módulo de ventas - Agregar nuevo diseño responsive - Corregir bug en cálculo de impuestos - Actualizar librería de UI - Añadir nueva funcionalidad de descuentos
✅ Commits Atómicos:
Separando cada cambio:
refactor(pos/ui): implementar diseño responsive fix(pos/tax): corregir cálculo de impuestos chore(deps): actualizar librería de UI a v2.1 feat(pos/discount): añadir sistema de descuentos
Un cambio, un commit
Cada commit debe representar una única modificación lógica. Si necesitas describir tu commit con "y", probablemente debas dividirlo.
Usa tiempo presente
"add feature" en lugar de "added feature"
Sé conciso pero descriptivo
El título no debe exceder 50 caracteres
Incluye el contexto necesario
Usa el cuerpo del commit para explicar el "por qué" del cambio
Referencias los issues
Incluye "Fixes #123" o "Relates to #456" cuando sea relevante
Commits frecuentes
Realiza commits pequeños y frecuentes en lugar de grandes commits al final del día
¿Cuándo hacer commit?
- Después de implementar una nueva función
- Al terminar una refactorización específica
- Cuando corriges un bug
- Al completar una mejora en el diseño
- Después de actualizar documentación
- Cuando terminas de escribir tests