Hacer commit — qué es, reglas de formato y trabajo con Git

Qué es un commit en Git

Un commit en Git es un objeto que almacena el estado de los archivos del proyecto en un momento determinado. Cada commit contiene una instantánea de todos los archivos rastreados, una referencia al commit padre y metadatos. A diferencia de otros sistemas de control de versiones, Git utiliza almacenamiento direccionable por contenido — cada objeto se identifica mediante un hash SHA-1 de su contenido.

Cuando un desarrollador hace commit de cambios, Git crea un objeto commit que almacena: un objeto tree (estructura de archivos), hash del commit padre, autor, committer, fecha y mensaje. Este objeto es inmutable — una vez creado, un commit no se puede modificar sin cambiar su hash. Esta inmutabilidad garantiza la integridad del historial del proyecto.

# Preparar cambios y hacer commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Ver detalles del commit
git log --oneline -3
git show HEAD

# Preparar todos los cambios y hacer commit en un solo paso
git commit -a -m "Update dependencies to latest versions"

Los commits forman un grafo acíclico dirigido (DAG), donde cada nuevo commit hace referencia al anterior. Esto permite navegar por el historial, revertir cambios y analizar la evolución de la base de código. Comprender la estructura del DAG de Git es la base para el trabajo avanzado con commits.

Cómo hacer commit de cambios correctamente

El proceso de commit en Git consta de dos etapas: agregar cambios al área de staging (índice) y crear el commit. El área de staging permite al desarrollador seleccionar qué cambios específicos se incluirán en el commit, incluso si se han modificado muchos archivos en el directorio de trabajo.

La regla de atomicidad es el principio clave de un buen commit. Cada commit debe contener un cambio lógico. Si un desarrollador corrige un error y refactoriza código — son dos commits diferentes. Los commits atómicos simplifican la revisión de código, la reversión de cambios y el análisis del historial.

Antes de hacer commit, vale la pena verificar: si quedan en el código salidas de depuración, bloques comentados o cambios accidentales. Para esto se usa el comando git diff --cached, que muestra qué se incluirá exactamente en el commit. Una verificación adicional con git status muestra la lista de archivos en el área de staging.

• Verifica los cambios — git diff --cached muestra qué se incluirá en el commit
• Verifica la calidad — el código debe pasar el linter y las pruebas antes del commit
• Escribe un mensaje — una descripción clara del propósito del cambio
• Verifica los archivos staged — git status confirma la lista de archivos

Reglas para escribir mensajes de commit

El mensaje de commit es la documentación del cambio para futuros desarrolladores. Un buen mensaje responde a las preguntas: qué se cambió y por qué. La convención Conventional Commits (equipo Angular, 2016) se ha convertido en un estándar para muchos proyectos y define el formato: tipo(ámbito): descripción.

Un buen mensaje de commit consta de un encabezado (hasta 50 caracteres) y un cuerpo (opcional, hasta 72 caracteres por línea). El encabezado se escribe en modo imperativo: “Add” no “Added” ni “Adds”. Capitalization y punto al final del encabezado no se usan — es una convención internacional de Git.

Un mal mensaje: “fix things” o “update” — no aporta información. En un mes, un desarrollador no podrá entender qué se cambió exactamente y por qué. Un buen mensaje: “fix(payment): handle timeout in stripe callback” — inmediatamente queda claro qué y dónde se corrigió.

Errores comunes al hacer commit

Los desarrolladores, especialmente los principiantes, suelen cometer errores típicos al hacer commit. El más común es un commit demasiado grande, que mezcla docenas de cambios. Tal commit no se puede revertir parcialmente, y la revisión de código se convierte en un suplicio.

El segundo error más frecuente es un mensaje de commit pobre. Mensajes como “fix”, “update”, “changes” o “wip” no proporcionan contexto a los futuros desarrolladores. En seis meses, nadie recordará qué se corrigió exactamente. La regla es simple: imagina que dentro de un año revisas el historial tratando de encontrar un cambio específico.

El tercer error es hacer commit de código no compilado o que no funciona. Después de un commit, el código debe al menos compilar. No romper la compilación es un requisito básico para cualquier commit en una rama compartida. Para ello, se ejecutan la compilación y las pruebas antes del commit.

El cuarto error es hacer commit de datos confidenciales. Las claves de API, contraseñas y tokens no deben terminar en el historial de Git. Si un secreto ya se ha commitido, no basta con eliminarlo en un nuevo commit, sino que hay que borrarlo de todo el historial mediante git filter-branch o BFG Repo-Cleaner.

Técnicas avanzadas de trabajo con commits

Git proporciona herramientas para gestionar el historial de commits. Una de las más útiles es git commit --amend, que permite complementar el último commit con nuevos cambios o corregir el mensaje. Es útil si el desarrollador olvidó incluir un archivo o cometió un error tipográfico en el mensaje.

# Corregir el último mensaje de commit
git commit --amend -m "fix(auth): correct token validation logic"

# Agregar archivo olvidado al último commit
git add missed-file.txt
git commit --amend --no-edit

# Rebase interactivo para los últimos 3 commits
git rebase -i HEAD~3

Interactive rebase es una herramienta potente para reescribir el historial. Permite combinar commits (squash), cambiar mensajes (reword), reordenar (reorder) y eliminar commits (drop). Sin embargo, rebase modifica el historial, por lo que se usa solo en commits locales que aún no se han enviado a un repositorio remoto.

Existen dos enfoques para revertir commits. git revert crea un nuevo commit que deshace los cambios del anterior — un método seguro que preserva el historial. git reset elimina commits del historial — peligroso si los commits ya se han enviado. En el desarrollo en equipo, solo se usa git revert para deshacer commits publicados.