Estados de los archivos: Untracked, modified, staged, committed

En Git, los archivos dentro de un repositorio pueden encontrarse en diferentes estados que reflejan su relación con el control de versiones. Para gestionar correctamente los cambios en un proyecto es necesario comprender estos estados.

• Untracked: Son archivos que existen en el directorio de trabajo pero que Git no está siguiendo todavía. No aparecen en el historial de commits y no serán incluidos en el repositorio hasta que se agreguen explícitamente. Por ejemplo, al crear un nuevo archivo:

echo. > nuevo_archivo.txt

Este archivo aparecerá como untracked al ejecutar:

git status

• Modified: Un archivo se considera modificado cuando ha sido editado después de su último commit o después de haber sido agregado al staging area. Git detecta que el contenido del archivo ha cambiado, pero los cambios aún no están preparados para ser confirmados. Por ejemplo, al modificar archivo_existente.txt:

echo "Nuevo contenido" >> archivo_existente.txt

• Staged: También conocido como indexado, este estado indica que los cambios en el archivo han sido agregados al staging area y están listos para ser confirmados en el siguiente commit. Se utiliza el comando:

git add archivo_existente.txt

Ahora, el archivo archivo_existente.txt está en estado staged.

• Committed: Un archivo está confirmado cuando sus cambios han sido guardados en el repositorio local mediante un commit. Esto significa que el estado del archivo en ese punto queda registrado en el historial de Git. Para confirmar los cambios staged:

git commit -m "Mensaje descriptivo del commit"

Seguimiento de cambios: Uso de git status y git diff

Para mantener un control eficaz de las modificaciones en un proyecto, Git proporciona herramientas esenciales como git status y git diff. Estas utilidades permiten a los desarrolladores supervisar el estado actual de los archivos y examinar los cambios realizados.

El comando git status ofrece una visión general del estado del repositorio local. Al ejecutarlo, proporciona información sobre:

• Archivos modificados pero no agregados al área de preparación.
• Archivos en el área de preparación listos para ser confirmados.
• Archivos sin seguimiento que Git aún no está rastreando.

El uso básico es simplemente:

git status

Después de realizar cambios en los archivos, git status ayuda a identificar qué archivos han sido modificados y cuál es su estado en el ciclo de vida de Git. Por ejemplo, tras modificar archivo.txt, la salida podría ser:

$ git status
En la rama main
Cambios no preparados para el commit:
  (usa "git add <archivo>..." para actualizar lo que se confirmará)
  (usa "git restore <archivo>..." para descartar cambios en el directorio de trabajo)
    modificado:   archivo.txt

Archivos sin seguimiento:
  (usa "git add <archivo>..." para incluir en lo que se confirmará)
    nuevo_archivo.txt

no hay nada agregado al commit pero hay archivos sin seguimiento presentes (usa "git add" para hacerles seguimiento)

En este ejemplo, git status indica que archivo.txt ha sido modificado y que nuevo_archivo.txt es un archivo sin seguimiento. Esta información es crucial para decidir qué cambios agregar al área de preparación con git add y cuáles dejar de lado.

El comando git diff permite ver las diferencias detalladas entre distintas versiones de los archivos. Es especialmente útil para revisar los cambios antes de confirmar un commit. Algunos usos comunes incluyen:

• Ver cambios no preparados: Comparar el directorio de trabajo con el área de preparación.

git diff

Esto muestra las diferencias entre los archivos modificados y su última versión confirmada. Por ejemplo, si ha añadido una línea a archivo.txt, git diff mostrará esa modificación.

• Ver cambios preparados: Comparar el área de preparación con el último commit.

git diff --staged

Útil para verificar exactamente qué se incluirá en el próximo commit.

• Comparar dos commits específicos:

git diff <commit1> <commit2>

Donde <commit1> y <commit2> son los identificadores de los commits a comparar.

Por ejemplo, si después de editar archivo.txt sin agregarlo al área de preparación, ejecutamos:

git diff

La salida podría ser:

diff --git a/archivo.txt b/archivo.txt
index e69de29..4b825dc 100644
--- a/archivo.txt
+++ b/archivo.txt
@@ -0,0 +1 @@
+Esta es una nueva línea en el archivo.

El signo + indica que se ha añadido una línea. Este nivel de detalle ayuda a revisar los cambios con precisión antes de confirmarlos.

Además, git diff admite opciones para personalizar la salida, como --color para resaltar modificaciones o --stat para obtener un resumen estadístico de las diferencias. Utilizar git status y git diff regularmente es fundamental para un seguimiento detallado de los cambios y para mantener la integridad del historial en el repositorio Git.

Confirmaciones de cambios (commits): Importancia de los mensajes descriptivos

En Git, una confirmación o commit representa un punto específico en el historial de desarrollo, registrando el estado del proyecto en un momento dado. Cada commit es como una captura del código en un instante, incluyendo todas las modificaciones realizadas. Por ello, la importancia de los mensajes descriptivos radica en la capacidad de comunicar claramente qué cambios se han efectuado y por qué.

Un mensaje de commit conciso y detallado facilita la comprensión del historial por parte de todo el equipo de desarrollo. Cuando se revisa el historial de commits, mensajes como "Arregla fallo en la validación de datos del formulario de registro" aportan información valiosa, evitando la necesidad de inspeccionar las diferencias en el código para entender el propósito del cambio.

Para redactar mensajes efectivos, es aconsejable seguir ciertas buenas prácticas:

• Utilizar el modo imperativo: Escribir como si se estuviera dando una orden, por ejemplo, "Corrige error en cálculo de impuestos" en lugar de "Corregido error en cálculo de impuestos".
• Ser específico y claro: Indicar exactamente qué se ha cambiado y en qué contexto. Evitar mensajes genéricos como "Actualizaciones" o "Cambios varios".
• Resumir en la primera línea: La primera línea debe ser un resumen breve del cambio (idealmente menos de 50 caracteres). Si se necesita más detalle, añadir una descripción adicional tras una línea en blanco.
• Explicar la razón del cambio: Si el motivo no es evidente, es útil incluir una breve explicación. Por ejemplo, "Actualiza dependencia a la versión 2.0 para solucionar incompatibilidades con el módulo de autenticación".

Al emplear el comando git commit, se puede especificar el mensaje directamente:

git commit -m "Implementa función de exportación a PDF en informes"

Si se requiere una descripción más extensa, es preferible omitir el parámetro -m y permitir que Git abra el editor predeterminado:

git commit

Dentro del editor, se puede escribir:

Añade soporte para múltiples idiomas en la interfaz de usuario

Se han incorporado traducciones para español y francés, y se ha implementado un mecanismo para facilitar la adición de nuevos idiomas en el futuro.

Aplicar mensajes de commit claros mejora la comunicación dentro del equipo y agiliza procesos como la resolución de errores y la revisión de código.

Buenas prácticas de commits: atómicos y fáciles de revertir

En Git, seguir buenas prácticas al realizar commits es fundamental para mantener un historial de cambios claro. Una de las prácticas más importantes es asegurar que los commits sean atómicos y fáciles de revertir.

Un commit atómico se refiere a un conjunto de cambios que implementa una única funcionalidad o resuelve un problema específico, sin mezclar modificaciones no relacionadas. Esto implica que cada commit debe ser lo más pequeño y coherente posible, enfocándose en una sola tarea. Los beneficios de los commits atómicos incluyen:

• Facilidad de rastreo: Permite identificar rápidamente cuándo y por qué se introdujo un cambio específico en el código.
• Simplificación de revisiones: Los code reviews se vuelven más eficientes al analizar cambios enfocados y bien delimitados.
• Reversión sencilla: Si un commit introduce un error, es más fácil revertirlo sin afectar otras partes del proyecto.

Para lograr commits atómicos y fáciles de revertir, se recomienda:

• Realizar cambios pequeños y enfocados: Evitar acumular múltiples modificaciones en un solo commit. Por ejemplo, si se corrige un bug y se agrega una nueva función, hacer commits separados para cada cambio.
• Agrupar cambios relacionados: Asegurarse de que todas las modificaciones en un commit estén directamente relacionadas entre sí y contribuyan a una sola finalidad.
• Evitar cambios de formato innecesarios: Ajustes de estilo, como espacios o indentaciones, deben realizarse en commits aparte para no mezclar con cambios funcionales.
• Probar antes de confirmar: Verificar que los cambios funcionan correctamente antes de hacer el commit, asegurando que cada punto en el historial es estable y funcional.
• Escribir mensajes claros y descriptivos: El mensaje debe reflejar precisamente la funcionalidad o corrección introducida, facilitando la comprensión del historial.

Una herramienta útil para crear commits atómicos es git add -p (o git add --patch), que permite seleccionar interactivamente los cambios a añadir al área de preparación. Esto es especialmente útil cuando se han realizado múltiples cambios en un mismo archivo que deberían estar en commits distintos. Por ejemplo:

git add -p archivo_modificado.js

Este comando presenta los cambios en fragmentos (hunks) y permite decidir cuáles incluir en el commit actual.

Si se ha añadido accidentalmente más cambios al área de preparación, se puede usar git reset para deshacer la preparación y reorganizarlos adecuadamente:

git reset archivo_modificado.js

Esto devuelve los cambios del archivo al estado de modificado, pudiendo luego preparar selectivamente las partes correctas.