Commits

Hacer commits y escribir mensajes descriptivos

El commit representa el momento en que guardamos permanentemente nuestros cambios en el historial de Git. Una vez que hemos preparado nuestros archivos en el área de staging, el siguiente paso es crear un commit que documente qué cambios hemos realizado y por qué.

Crear un commit desde Visual Studio Code

Para realizar un commit en VSCode, necesitamos utilizar el campo de mensaje que aparece en la parte superior del panel Source Control. Este campo de texto es donde escribiremos la descripción de nuestros cambios antes de confirmarlos.

Message (press Ctrl+Enter to commit)

Una vez que tengamos archivos en el área de staging y hayamos escrito nuestro mensaje, podemos ejecutar el commit de varias formas:

• Presionando Ctrl+Enter mientras el cursor está en el campo de mensaje
• Haciendo clic en el botón "Commit" que aparece junto al campo de mensaje
• Usando el menú contextual del panel Source Control

Cuando el commit se ejecuta correctamente, los archivos desaparecen del área de staging y el contador de cambios en el icono de Source Control se actualiza para reflejar el nuevo estado del repositorio.

Escribir mensajes de commit efectivos

Un mensaje de commit descriptivo es fundamental para mantener un historial claro y útil. VSCode nos ayuda a escribir buenos mensajes proporcionando un campo de texto prominente y recordatorios visuales sobre las mejores prácticas.

La estructura recomendada para un mensaje de commit incluye:

Línea de resumen (máximo 50 caracteres):

Añadir validación de formulario de contacto

Descripción detallada (opcional):

Añadir validación de formulario de contacto

- Validar campos obligatorios antes del envío
- Mostrar mensajes de error específicos
- Implementar validación de formato de email
- Añadir feedback visual para campos inválidos

Para mensajes más largos, podemos presionar Enter después de la línea de resumen para crear una descripción extendida. VSCode respeta esta convención y formatea el mensaje correctamente.

Buenas prácticas para mensajes descriptivos

Los mensajes de commit deben seguir ciertas convenciones que faciliten la comprensión del historial:

Usar el imperativo en la línea de resumen:

• ✅ "Corregir error en cálculo de impuestos"
• ❌ "Corregido error en cálculo de impuestos"

Ser específico sobre los cambios realizados:

• ✅ "Añadir botón de cancelar en modal de confirmación"
• ❌ "Actualizar interfaz"

Explicar el qué y el por qué, no el cómo:

• ✅ "Optimizar consulta de usuarios para mejorar rendimiento"
• ❌ "Cambiar SELECT por JOIN en línea 45"

Agrupar cambios relacionados en un solo commit:

Implementar sistema de autenticación

- Añadir middleware de autenticación
- Crear páginas de login y registro
- Configurar sesiones de usuario
- Añadir protección a rutas privadas

Verificar el commit antes de confirmar

Antes de ejecutar el commit, VSCode nos permite revisar exactamente qué cambios estamos confirmando. En el panel Source Control podemos:

• Expandir cada archivo para ver las líneas modificadas
• Hacer clic en un archivo para abrir la vista de diferencias
• Verificar que todos los cambios relacionados estén incluidos

Esta verificación es especialmente importante cuando trabajamos con múltiples archivos o cuando hemos realizado cambios en diferentes partes del proyecto.

Ver el historial de commits

Una vez realizado el commit, podemos verificar que se ha registrado correctamente accediendo al historial de commits. VSCode proporciona varias formas de visualizar este historial:

Desde la paleta de comandos (Ctrl+Shift+P):

Git: View History

O utilizando la vista de Timeline en el explorador, que muestra los commits recientes del archivo actualmente abierto junto con otros eventos del historial.

El historial nos muestra información esencial de cada commit:

• Hash del commit (identificador único)
• Mensaje del commit que escribimos
• Autor y fecha del commit
• Archivos modificados en ese commit

Esta información nos permite rastrear la evolución del proyecto y entender qué cambios se realizaron en cada momento del desarrollo.

Diferencias entre cambios staged y unstaged

Es importante comprender la diferencia visual que VSCode nos muestra entre los cambios que están preparados para commit y los que no:

Los cambios staged aparecen en la sección "Staged Changes" con:

• Un icono de marca de verificación verde
• El botón "-" para hacer unstage
• Están listos para ser incluidos en el próximo commit

Los cambios unstaged aparecen en la sección "Changes" con:

• Un icono que indica el tipo de modificación (M para modificado, A para añadido)
• El botón "+" para hacer stage
• No se incluirán en el commit hasta que los movamos al área de staging

Esta separación visual nos permite controlar exactamente qué cambios queremos incluir en cada commit, facilitando la creación de commits más focalizados y descriptivos.

Contexto histórico: del patch al commit moderno

Antes de Git, los desarrolladores gestionaban cambios de forma muy rudimentaria: enviaban parches generados con diff por correo electrónico o subían archivos completos a un servidor FTP. Herramientas como CVS (1990) y Subversion (2000) introdujeron el concepto de commit como transacción atómica, pero con limitaciones importantes, como la dependencia de un servidor central. Git, creado por Linus Torvalds en 2005 para el kernel de Linux, reinventó el concepto al ofrecer commits distribuidos con identificadores criptográficos (SHA-1) que garantizan la integridad del historial. Visual Studio Code aprovecha todo este legado al integrar una interfaz visual para crear commits sin ocultar la potencia subyacente de Git.

Atajos de teclado adicionales

Además del atajo principal, existen comandos útiles para trabajar con commits:

• Ctrl + Shift + G: abre el panel Source Control.
• Ctrl + Enter: confirma el commit con el mensaje escrito.
• Ctrl + Shift + P y Git: Commit: alternativa al atajo principal.
• Ctrl + Shift + P y Git: Commit Staged: confirma únicamente los cambios staged.
• Ctrl + Shift + P y Git: Commit All: confirma todos los cambios, staged o no.
• Ctrl + Shift + P y Git: Undo Last Commit: deshace el último commit manteniendo los cambios.
• Ctrl + Shift + P y Git: Stage All Changes: mueve todos los cambios al área de staging.
• Ctrl + Shift + P y Git: Unstage All Changes: saca todos los cambios del staging.

Ejemplo paso a paso: commit siguiendo Conventional Commits

Imagina que has añadido un nuevo endpoint POST /api/orders y quieres hacer commit siguiendo la convención Conventional Commits:

1. Revisa los cambios con Ctrl + Shift + G y haz clic en cada archivo modificado para comparar con la versión anterior.
2. Asegúrate de que solo los archivos relacionados con el endpoint están en staging (no mezcles con otros cambios).
3. En el campo de mensaje, escribe la línea de resumen siguiendo el formato: feat(orders): add POST endpoint to create orders.
4. Pulsa Enter dos veces para crear una descripción extendida.
5. Escribe: - Add OrderController with POST handler\n- Add OrderService with validation\n- Add integration tests for happy path and validation errors.
6. Pulsa Ctrl + Enter para confirmar el commit.
7. Verifica en la pestaña Graph del Source Control que el commit aparece con el mensaje correcto.
8. Si algo falló, usa Git: Undo Last Commit y repite el proceso.

Tabla comparativa: formatos de mensajes de commit

| Formato | Ejemplo | Uso típico | |---------|---------|------------| | Conventional Commits | feat(auth): add OAuth login | Proyectos con changelog automático | | Gitmoji | :sparkles: Add OAuth login | Proyectos con énfasis visual | | Libre | Añadir login con OAuth | Equipos sin convenciones estrictas | | Ticket-referenced | [JIRA-1234] Add OAuth login | Integración con gestores de tickets | | Angular-style | feat(auth): add oauth login | Frameworks y librerías populares |

Errores comunes al hacer commits

Varios tropiezos habituales:

• Commits gigantes con decenas de archivos y cambios no relacionados, imposibles de revisar.
• Mensajes vagos como "fix", "update" o "wip", que no aportan información útil al historial.
• Confundir staged y unstaged: hacer commit sin revisar lleva a incluir cambios no deseados.
• Olvidar configurar user.name y user.email, lo que hace que los commits aparezcan con datos del sistema.
• Commitear archivos de configuración local como .env o credenciales, un problema de seguridad grave.
• Usar git add . sin revisar: puede incluir archivos temporales o dependencias no deseadas.

Mejores prácticas en equipos

En proyectos colaborativos, los commits son el principal canal de comunicación entre desarrolladores:

• Adoptar una convención clara (por ejemplo, Conventional Commits) y documentarla en el README.md.
• Usar un hook pre-commit con herramientas como Husky o lefthook para validar el formato del mensaje.
• Configurar un hook pre-commit que ejecute linters y tests antes de permitir el commit, evitando commits rotos.
• Aprovechar la extensión GitLens para ver información adicional sobre cada commit directamente en el editor.
• Revisar los commits en los pull requests como parte del proceso de revisión de código, no solo el diff final.
• Evitar las enmiendas a commits ya publicados (git commit --amend) porque reescriben la historia y causan conflictos a otros miembros del equipo.