Dominando Git Stage y Commit: Tus Primeros Cambios

Dominar los conceptos básicos de Git stage y commit es el primer paso real para usar Git con confianza. El staging te permite elegir exactamente qué incluir en la siguiente instantánea, y el commit registra esa instantánea con un mensaje que los lectores futuros puedan entender.

Si tratas cada commit como una unidad de trabajo pequeña y revisable, Git se vuelve mucho más fácil de usar. Puedes inspeccionar cambios, dividir ediciones no relacionadas y recuperarte de errores sin pánico.

Cómo Funciona el Área de Staging

Git no hace commit automáticamente de cada archivo que editas. Separa tu trabajo en el árbol de trabajo, el área de staging y el historial de commits.

El árbol de trabajo es tu carpeta de proyecto. Estos son los archivos que editas en tu editor.

El área de staging es la lista de verificación de Git para el próximo commit. Cuando ejecutas git add, aún no estás guardando historial. Estás seleccionando cambios para el próximo commit.

El historial del repositorio es la secuencia de commits ya registrados.

Comienza verificando el estado:

git status

Git mostrará archivos no rastreados, archivos modificados, cambios staged y tu rama actual. Este comando es seguro de ejecutar en cualquier momento y debería convertirse en un hábito.

Para agregar un archivo nuevo o modificado:

git add README.md

Para agregar todos los cambios en el directorio actual:

git add .

Ese comando es conveniente, pero úsalo con cuidado. Puede agregar archivos no relacionados, configuraciones locales o salida generada si tu .gitignore está incompleto.

Para una revisión más segura, primero inspecciona el diff:

git diff

Luego agrega solo lo que pertenece junto:

git add src/app.js
git add README.md

Después de agregar, verifica qué se va a commitear:

git diff --staged

Esto muestra la instantánea exacta que se va a commitear. Si algo parece incorrecto, arréglalo antes de hacer commit.

Haciendo Tu Primer Commit

Una vez que los cambios correctos están en el área de staging, crea un commit:

git commit -m "Agregar README del proyecto"

El mensaje debe describir el cambio, no la acción que realizaste. "Agregar README del proyecto" es más útil que "cambios" o "actualizar archivos".

Un buen commit generalmente tiene un propósito claro. Por ejemplo, supongamos que actualizas un script de despliegue y también corriges un error tipográfico en una página de documentación. Esos son cambios separados. Agrúpalos y haz commit por separado:

git add scripts/deploy.sh
git commit -m "Agregar verificación de salud del despliegue"

git add docs/setup.md
git commit -m "Corregir error tipográfico en guía de configuración"

Esto facilita la revisión. También facilita el rollback si el cambio de despliegue causa un problema pero la corrección de documentación está bien.

Si ejecutas git commit sin -m, Git abre tu editor. Esto es útil cuando necesitas un mensaje más largo:

Agregar verificación de salud del despliegue

Verificar el endpoint del servicio antes de marcar el despliegue como completo.
Esto ayuda a detectar inicios fallidos más temprano en el proceso de lanzamiento.

La primera línea debe ser corta y directa. El cuerpo puede explicar por qué se necesitó el cambio o mencionar compensaciones.

Para ver commits recientes:

git log --oneline -5

Esto te da una vista compacta del historial reciente.

Agregando Partes de un Archivo

A veces un archivo contiene múltiples ediciones no relacionadas. Git puede agregar solo una parte de un archivo con el modo patch:

git add -p src/config.js

Git muestra cada bloque de cambio y pregunta qué hacer. Las opciones comunes son:

• y: agregar este bloque.
• n: no agregar este bloque.
• s: dividir el bloque en partes más pequeñas si es posible.
• q: salir del modo patch.

El patch staging es útil cuando estás limpiando antes de un commit. Por ejemplo, podrías tener un archivo donde agregaste una nueva configuración de tiempo de espera y también reformateaste un comentario. Agrega el cambio de tiempo de espera para un commit, luego agrega la limpieza del comentario para otro.

Si agregaste algo por error, quítalo del staging sin descartar tu trabajo:

git restore --staged src/config.js

Tu archivo permanece modificado en el árbol de trabajo. Simplemente se elimina del área de staging.

Si quieres descartar cambios no agregados en un archivo, ten cuidado:

git restore src/config.js

Ese comando descarta las ediciones locales en ese archivo. Ejecuta git diff primero para saber qué estás perdiendo.

Para más patrones de recuperación, consulta cómo deshacer errores de Git.

Higiene de Commits para el Trabajo Diario

Los commits pequeños y enfocados son más fáciles de revisar, probar y revertir. También hacen que herramientas como git bisect sean más útiles cuando necesitas encontrar dónde comenzó un error.

Usa estos hábitos:

• Ejecuta git status antes de agregar.
• Revisa git diff antes de git add.
• Revisa git diff --staged antes de hacer commit.
• Mantén cambios no relacionados en commits separados.
• Escribe mensajes que expliquen qué cambió.
• Evita hacer commit de archivos generados a menos que el proyecto los espere.
• Nunca hagas commit de secretos, claves privadas o valores locales de .env.

Un flujo de trabajo práctico podría verse así:

git status
git diff
git add src/server.js
git diff --staged
git commit -m "Manejar respuesta faltante de verificación de salud"
git status

Esa secuencia no es llamativa, pero detecta la mayoría de los errores de principiantes. Sabes qué cambió, qué está en el área de staging, qué se commitó y qué queda.

Si tu equipo usa hooks de pre-commit o formato automático, un commit puede fallar hasta que arregles el formato o las pruebas. Lee el mensaje de error, ejecuta el comando sugerido, agrega los cambios resultantes y haz commit de nuevo.

Cuándo Pedir Ayuda

Pide ayuda si accidentalmente agregaste o hiciste commit de secretos, si hiciste commit en la rama equivocada, o si no estás seguro de si debes modificar, revertir, resetear o hacer un nuevo commit. Esas opciones tienen diferentes efectos, especialmente después de un push.

También debes preguntar antes de reescribir commits que otras personas puedan haber descargado. Una simple limpieza local puede convertirse en un problema de equipo si cambia el historial compartido.

El staging y los commits son el ciclo central de Git. Revisa tus cambios, agrega intencionalmente, haz commit en piezas enfocadas y escribe mensajes que tengan sentido dentro de un mes.