Cómo funciona
Un commit es la unidad básica de historial en Git. Cuando modificas archivos y ejecutas git commit, Git crea una instantánea de ese estado, con un identificador único (hash), la fecha, el autor y un mensaje descriptivo. Esa instantánea queda almacenada en el repositorio y puede recuperarse en cualquier momento.
Los buenos commits son pequeños y se enfocan en un único cambio lógico. El mensaje debe explicar el por qué del cambio, no solo el qué cambió. Los proyectos siguen convenciones como Conventional Commits, que estandarizan prefijos como feat:, fix: y docs:.
Los commits forman una cadena: cada commit apunta al anterior, creando un historial lineal o ramificado. Esto permite volver en el tiempo, comparar versiones e identificar cuándo apareció un bug.
Antes del commit, los cambios quedan en el área de preparación, donde seleccionas exactamente qué alteraciones incluir. Buenas prácticas incluyen commits atómicos, mensajes en imperativo y referencia a issues cuando aplica. Los hooks de pre-commit pueden ejecutar linters y pruebas automáticamente antes de confirmar el commit.
Reescribir el historial con rebase o amend exige cuidado en ramas compartidas, ya que puede causar conflictos para otros colaboradores. Los commits firmados con GPG aumentan la seguridad y la trazabilidad.
Ejemplo práctico
Corriges un bug en el cálculo de impuestos y ajustas dos archivos. En lugar de hacer commit de todo junto con "correcciones", creas dos commits: uno con "fix: corrige cálculo de impuesto para clientes persona jurídica" y otro con "test: agrega test para el escenario de persona jurídica". Así, el historial queda claro y fácil de revertir si es necesario.
Para qué sirve
Los commits organizan el trabajo y permiten colaboración segura. En equipos, cada persona crea commits en su rama y los envía vía pull request para revisión. Las herramientas de CI/CD disparan pruebas automáticamente con cada commit.
Agentes de IA que programan, como Claude Code y Codex, también crean commits al finalizar tareas. En bridgecode, cada agente puede trabajar en su propia rama y hacer commits de cambios aislados, facilitando la revisión humana antes del merge.