Sinopsis

git commit [-m <msg>] [-a] [--amend] [--no-verify] [-S]

Descripción

El comando git commit toma todo lo que está actualmente en el área de staging y crea un nuevo objeto commit en el repositorio. Un commit es una instantánea inmutable que contiene un tree (los contenidos de los archivos), puntero(s) padre, metadatos de author y committer, y un mensaje. Los commits son la unidad de historial en Git: los branches son punteros a commits, los merges producen commits con múltiples padres y los tags etiquetan commits específicos.

Un buen mensaje de commit tiene una línea de asunto corta (menos de 50 caracteres), una línea en blanco y un cuerpo opcional explicando el por qué. Muchos equipos usan conventional commits u otros sistemas de prefijos. La opción --amend modifica el commit más reciente, útil para arreglar typos en el mensaje u olvidar stagear un archivo, pero nunca enmiendes un commit que ya ha sido pusheado y compartido.

En el uso diario, git commit se integra estrechamente con alias de shell, plugins de editor e integración continua. Los usuarios avanzados a menudo añaden alias que combinan los flags que siempre pasan, o envuelven el comando en scripts que hacen cumplir convenciones de equipo. El formato de salida puede personalizarse vía configuración de Git: formatos pretty, esquemas de color y comportamiento del paginador son ajustables. Cuando algo sale mal, el primer paso de diagnóstico suele ser re-ejecutar el comando con GIT_TRACE=1 en el entorno, lo que revela las llamadas plumbing subyacentes. Para situaciones inusuales, la salida de --help (git commit --help) abre la página de manual completa con detalles de cada opción, incluyendo aquellas raramente usadas en flujos casuales pero esenciales para depuración o scripting a escala.

Entender cómo git commit interactúa con el resto del modelo de datos de Git (la base de datos de objetos, el index, las refs y el árbol de trabajo) rinde dividendos. Cada comando opera sobre algún subconjunto de estas piezas, y saber cuáles toca ayuda a predecir resultados y a recuperarse de errores. Leer la documentación oficial de Git junto con práctica práctica en un repositorio desechable es la forma más rápida de internalizar los matices. La mayoría de problemas de producción con Git provienen de una de tres causas: comportamiento predeterminado sorprendente, operaciones de red parciales, o reescribir historial que ya se compartió. Un modelo mental funcional de los efectos secundarios de git commit ayuda a evitar las tres.

Opciones comunes

Ejemplos

git commit -m "Fix off-by-one error in pagination"
# Commit rápido con mensaje de una línea

git commit -am "Update README"
# Stagea cambios rastreados y commitea en un paso

git commit --amend -m "Better message"
# Reescribe el mensaje del commit más reciente

git commit --fixup=abc123
# Crea un commit fixup para ser squasheado durante rebase

Errores comunes

Enmendar un commit publicado y luego hacer force-push reescribe el historial sobre el que otros pueden haber basado trabajo, causando confusión. Solo enmienda commits locales, no compartidos. Otro error es commitear con -a cuando los archivos no rastreados también deberían incluirse: -a ignora archivos nuevos. Finalmente, nunca uses --no-verify solo para saltarte tests que fallan; arregla el test o el código.

Comandos relacionados

git add, git status, git log, git revert