La semana pasada se presento el lanzamiento de la nueva versión del sistema de control de fuente distribuida Git 2.23. En comparación con la versión anterior, se realizaron poco más de 500 cambios en esta nueva versión.

Pero entre las mejoras recientemente introducidas en esta nueva versión, las que reciben la mayor atención son git switch y git restore, estos son dos comandos experimentales específicos que pueden usarse para reemplazar en cierta medida el comando git checkout. Para quienes desconocen de git, deben saber que este es uno de los sistemas de control de versiones más populares, confiables y de alto rendimiento que proporciona herramientas flexibles de desarrollo no lineal basadas en la ramificación y fusión de versiones.

Para garantizar la integridad de la historia y la resistencia a los cambios en retrospectiva, se utiliza un hash implícito de toda la historia previa en cada confirmación, y también es posible firmar digitalmente a los desarrolladores de etiquetas y confirmaciones individuales.

Principales novedades de git 2.23

En esta nueva versión de git se presentan los comandos experimentales antes mencionados “git switch y git restore”.

Estos nuevos comandos están diseñados para separar las funciones “git checkout” sueltas, como la manipulación de ramas (cambio y creación) y la restauración de archivos en el directorio de trabajo (“git checkout $ commit - $ filename” ) o inmediatamente en el área de preparación (“--staging“, no tiene ningún análogo en el “git checkout“).

Vale la pena señalar que, a diferencia de “git checkout“, “git restore” elimina los archivos no rastreados de los directorios restaurados (“–no-overlay” por defecto).

Con git restore, es mucho más fácil determinar exactamente qué archivos cambiarán, cómo cambiarán y dónde cambiarán. De hecho, en lugar de usar el complicado comando git checkout, git restore proporciona 2 opciones para especificar dónde irán los cambios restaurados.

Por lo tanto, si pasa el parámetro --worktree (o no especifica nada), los cambios se realizarán en el repositorio de su disco duro. Sin embargo, si pasa el parámetro --staged, los cambios irán al índice. Finalmente, si pasa ambos parámetros, los cambios irán a las dos ubicaciones respectivas.

En git 2.23 se agregó la opción “git merge --quit“, que, como “–abort”, detiene el proceso de fusión de ramas, pero deja intacto el directorio de trabajo. Esta opción puede ser útil si es preferible emitir algunos de los cambios realizados durante la fusión manual como una confirmación por separado.

Los comandos git clone, git fetch y git push ahora tienen en cuenta la presencia de commits en repositorios vinculados ( alternativos ).

Se agregaron las opciones “git blame --ignore-rev” y “--ignore-revs-file” para omitir las confirmaciones que hicieron modificaciones menores (por ejemplo, arreglos de formato);

Por otro lado podremos encontrar la adición de la opción “git cherry-pick --skip” para omitir el compromiso de conflicto (análogo memorizado de la secuencia “git reset y git cherry-pick --continue“)

A partir de esta versión, git log tendrá en cuenta de manera predeterminada los cambios realizados por mailmap, similar a lo que ya está sucediendo en git shortlog.

La operación de actualización del gráfico commit (core.commitGraph) presentado en 2.18 se aceleró significativamente. También aceleró git para cada referencia en caso de usar varias plantillas y redujo el número de llamadas de auto-gc en “git fetch --multiple“.

Se ha agregado la configuración status.aheadBehind, fijando la opción “git status - [no-] ahead-behind” de forma continua.

“git branch --list” ahora siempre muestra HEAD separado al comienzo de la lista, independientemente de la configuración regional.

Más allá de estas mejoras, esta nueva versión de Git ahora puede usar las referencias de otra solución como parte de la verificación del objeto conectado que puede ocurrir cuando clona un repositorio y especifica otro durante la clonación o en otro.

Si quieres conocer mas al respecto puedes consultar el siguiente enlace.