git diff: comparación de cambios, modos de uso (working directory vs. staged)

El comando git diff sirve para ver las diferencias entre versiones de archivos en Git, comparando cambios en el directorio de trabajo, el área de preparación (staging area) y los commits confirmados en el repositorio.

Para ver los cambios realizados en el directorio de trabajo que aún no han sido añadidos al área de preparación, se utiliza:

git diff

Este comando muestra las diferencias entre los archivos modificados y su última versión confirmada. Sirve para revisar qué modificaciones se han hecho antes de añadirlas al área de preparación.

Si se quiere comparar los cambios que ya se han preparado para el commit, es decir, los que se han añadido al área de preparación con git add, se usa:

git diff --staged

O de forma equivalente:

git diff --cached

Este comando muestra las diferencias entre el área de preparación y el último commit. Así, se puede verificar exactamente qué se incluirá en el próximo commit antes de confirmarlo.

Para comparar cambios entre el directorio de trabajo y el área de preparación, por ejemplo, para ver las modificaciones en archivos que aún no se han añadido, especifica el archivo:

git diff nombre_archivo

Esto muestra las diferencias del archivo en el directorio de trabajo respecto a su versión en el área de preparación. Sirve para cuando se trabaja en varios archivos y se quieren revisar cambios específicos.

También se puede utilizar git diff para comparar los contenidos entre dos commits o ramas. Por ejemplo, para comparar dos commits específicos:

git diff commit1 commit2

Esto muestra las diferencias entre los dos commits identificados por sus hashes. Para comparar ramas:

git diff rama1 rama2

Así se puede ver las diferencias entre dos ramas antes de fusionarlas, anticipando posibles conflictos.

Si solo se quiere un resumen de los archivos que han cambiado sin detalle de las modificaciones, se utiliza:

git diff --name-only

Este comando devuelve una lista de los nombres de los archivos modificados, para una visión rápida de los cambios.

Para obtener estadísticas sobre los cambios, como el número de líneas añadidas o eliminadas, se usa:

git diff --stat

Esto ofrece un resumen cuantitativo para entender hasta donde llegan las modificaciones.

git blame: rastreo de autores en cada línea de un archivo

El comando git blame sirve para identificar quién modificó cada línea de un archivo a lo largo del tiempo y se puede rastrear la autoría de cada cambio.

Para emplear git blame, se ejecuta:

git blame nombre_archivo

Este comando muestra, para cada línea del archivo, el identificador del commit, el autor, la fecha de la última modificación y el contenido de la línea. Por ejemplo:

git blame app.py

Esto proporciona una vista detallada de quién modificó cada parte de app.py y cuándo se realizó cada cambio.

Si se quieren mostrar las direcciones de correo electrónico de los autores, se puede utilizar la opción -e:

git blame -e nombre_archivo

Esta opción se usa cuando varios colaboradores tienen nombres parecidos, porque las direcciones de correo son más diferentes y permiten identificar más fácilmente al autor.

Si se quiere enfocar en una sección específica del archivo, git blame permite limitar el análisis a un rango de líneas con la opción -L:

git blame -L inicio,fin nombre_archivo

Por ejemplo, para analizar desde la línea 50 hasta la 100:

git blame -L 50,100 app.py

Se utiliza cuando solo te interesa una parte concreta del código.

En casos donde el archivo ha sido movido o renombrado, se puede utilizar la opción -C para que git blame siga el rastro de los cambios:

git blame -C nombre_archivo

Así, se consigue información sobre modificaciones que se realizaron antes del movimiento.

Si lo que se quiere es entender el por qué de las modificaciones ignorando los cambios en espacio en blanco, se usa la opción -w:

git blame -w nombre_archivo

Esto se usa mucho cuando se han realizado reformateos del código que afectan a la indentación o espaciado.

Para analizar cómo se ha modificado una función específica, se puede combinar git blame con herramientas como grep:

git blame nombre_archivo | grep 'nombre_funcion'

Y se filtran las líneas relacionadas con nombre_funcion.

Además, git blame puede integrarse en entornos de desarrollo. Por ejemplo, extensiones en Visual Studio Code o IntelliJ IDEA muestran información de git blame al pasar el ratón sobre una línea.

Visualización de diferentes versiones: uso de git checkout para moverse entre commits

El comando git checkout permite moverse entre commits específicos para acceder a diferentes estados del repositorio.

Para desplazarse a un commit particular, primero se debe identificar el hash del commit al que se quiera acceder. Se puede obtener este identificador utilizando:

git log --oneline

Este comando muestra una lista resumida de commits, presentando los hashes abreviados y los mensajes asociados. Una vez que se tiene el hash, se utiliza git checkout seguido del identificador del commit:

git checkout abc1234

En este ejemplo, abc1234 representa los primeros caracteres del hash del commit. Cuando se ejecuta este comando, Git actualiza el directorio de trabajo al estado exacto que tenía en ese commit. Al hacer esto, se entra en el estado detached HEAD.

Estar en detached HEAD significa que no se está en ninguna rama en particular, sino apuntando directamente a un commit específico. Si se realizan cambios y se hace un commit en este estado, esos cambios no pertenecerán a ninguna rama existente y se pueden perder si se cambia de commit de nuevo. Para evitar esto, se recomienza crear una rama nueva basada en ese commit:

git checkout -b nueva-rama

Este comando crea y cambia a una nueva rama llamada nueva-rama, permitiendo conservar cualquier cambio que se haga a partir de ahí.

Si solo se quiere explorar el estado del proyecto en un commit anterior sin hacer modificaciones, uno puede moverse libremente y luego regresar a su rama principal con:

git checkout main

Devuelve a la rama main, restableciendo el directorio de trabajo al último commit de dicha rama. Se suele confirmar que se está en la rama correcta antes de continuar trabajando para evitar confusiones.

Cuando se trabaja con varias ramas, también se puede utilizar git checkout para cambiar entre ellas:

git checkout desarrollo

Este comando cambia el directorio de trabajo a la rama desarrollo, actualizando los archivos al último estado confirmado en esa rama.

Al cambiar a una rama, Git te sitúa en el último commit de esa rama y mantiene el seguimiento de futuros commits. Al cambiar a un commit específico, se entra en el estado de detached HEAD y no se sigue ninguna rama.

Si se necesita regresar al commit anterior o moverse por el historial, se puede utilizar:

git checkout HEAD~1

Donde ~1 indica que te mueves un commit atrás desde la posición actual de HEAD. Se puede ajustar el número para retroceder más commits.

Hay que tener cuidado al moverse entre commits si se tienen cambios sin confirmar en el directorio de trabajo. Si se intenta cambiar de commit con modificaciones pendientes, Git advierte sobre conflictos. Para guardar temporalmente los cambios antes de cambiar de commit, se utiliza:

git stash

Esto almacena los cambios en un lugar seguro, permitiendo recuperarlos más tarde con git stash pop.

Al navegar por diferentes versiones del proyecto, se puede utilizar git show para inspeccionar detalles de un commit:

git show abc1234

Esto muestra la información del commit identificado por abc1234, incluyendo el mensaje del commit y las diferencias introducidas.

Opciones de git log: Formatos, filtros, alias útiles (ej. --oneline, --graph)

El comando git log sirve para visualizar el historial de commits del repositorio. La salida predeterminada es larga y difícil de leer, así que se suelen utilizar opciones para filtrar la información.

Para obtener un resumen conciso de los commits, se puede utilizar la opción --oneline:

git log --oneline

Este comando muestra cada commit en una sola línea, incluyendo el identificador abreviado del commit y el mensaje corto.

Si se quiere visualizar el grafo de commits y las ramas de manera más gráfica, se puede emplear --graph:

git log --oneline --graph

Si se combina --oneline y --graph se ve una representación gráfica del historial, mostrando cómo se relacionan los commits y cómo divergen y convergen las ramas. Para añadir información sobre las ramas y los remotos, se puede incluir --all y --decorate:

git log --oneline --graph --all --decorate

Con esta opción, además de ver el grafo, se muestran las etiquetas de las ramas locales y remotas, y sirve para identificar dónde se encuentran los punteros de las ramas en el historial.

Para filtrar los commits por autor, se puede utilizar la opción --author seguida de una cadena de búsqueda:

git log --author="Nombre del Autor"

Este comando mostrará únicamente los commits realizados por el autor que se especifica. Sirve para revisar las contribuciones de un desarrollador en particular.

Si se necesita buscar commits que contengan una palabra clave en el mensaje, se puede usar --grep:

git log --grep="bugfix"

Esto devolverá una lista de commits cuyos mensajes incluyan la palabra "bugfix", se usa mucho para localizar cambios sobre incidencias.

También es posible filtrar por fecha usando las opciones --since y --until:

git log --since="2 weeks ago"

Este comando muestra los commits realizados en las últimas dos semanas. Se pueden combinar las dos opciones para definir un rango de fechas:

git log --since="2023-01-01" --until="2023-12-31"

Para limitar el número de commits mostrados, se utiliza -n seguido de la cantidad que se quiere:

git log -n 5

Esto muestra los 5 commits más recientes. Sirve para acotar la información cuando se trabaja con proyectos con un historial muy largo.

La opción --stat da un resumen de los cambios realizados en cada commit, mostrando cuántas líneas han sido añadidas o eliminadas en cada archivo:

git log --stat

Para obtener una vista aún más detallada, donde se incluyen las diferencias en los archivos, se puede usar -p:

git log -p

Este comando muestra los parches aplicados en cada commit, es decir, los cambios línea por línea, similar a git diff.

Los formatos personalizados permiten definir cómo se presenta cada commit. La opción --pretty ofrece varios formatos predefinidos, como oneline, short, full, fuller y format. Por ejemplo:

git log --pretty=short

Si se quiere un formato completamente personalizado, se puede especificar con format:

git log --pretty=format:"%h - %an, %ar : %s"

Aquí, %h es el hash abreviado, %an el nombre del autor, %ar el tiempo transcurrido desde el commit y %s el mensaje del commit.

Para simplificar el uso de comandos largos o que se usan mucho, se pueden crear alias personalizados. Por ejemplo, para definir un alias que muestra el historial con --oneline, --graph, --all y --decorate, se puede agregar al archivo de configuración .gitconfig:

git config --global alias.hist "log --oneline --graph --all --decorate"

Después de crear este alias, se puede usar simplemente:

git hist

Este comando ejecutará la configuración definida, ahorrando tiempo.

Los alias pueden ser cambiados directamente editando el archivo .gitconfig en el directorio de usuario, añadiendo entradas en la sección [alias]:

[alias]
    co = checkout
    br = branch
    ci = commit
    st = status

Estos alias comunes permiten utilizar comandos más cortos como git co en lugar de git checkout.