Se ha dado a conocer la liberación de la nueva versión del sistema de control “Git 2.25.0”, el cual 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 “retroactivamente”, se utiliza un hash implícito de toda la historia previa en cada confirmación, también es posible firmar digitalmente a los desarrolladores de etiquetas y confirmaciones individuales.

En comparación con el lanzamiento anterior, la nueva versión adoptó 583 cambios preparados con la participación de 84 desarrolladores, de los cuales 32 participaron en el desarrollo por primera vez.

¿Qué hay de nuevo en Git 2.25.0?

En esta nueva versión se destaca en el anuncio, la posibilidad de la clonación parcial, la cual ya esta cerca de ser estabilizada. Esta, permite transferir solo una parte de los datos y trabajar con una copia incompleta del repositorio.

La clonación parcial pretende ser una mejora para la clonación normal en la cual todos los datos se copian del repositorio, incluida cada versión de cada archivo en el historial de cambios. Para repositorios muy grandes, la copia de datos conduce a un aumento significativo en el tráfico y el espacio en disco, incluso si el desarrollador solo está interesado en un subconjunto de archivos.

Para simplificar la obtención de solo una parte del árbol de origen de trabajo, la nueva versión ofrece el comando experimental de comprobación escasa y la nueva opción.

git clone --filter=blob:none --no-checkout /your/repository/here

Especificar --filter: permite decirle al servidor que está clonando a partir de los objetos que elija. (En nuestro ejemplo, le pedimos al servidor que evite enviarnos blobs, pero puede usar varios calificadores posibles). 

A continuación, tenemos que decirle a Git que puede omitir la comprobación del repositorio después de recibir una respuesta del servidor con --no-checkout (ya que Git intenta verificar el contenido, se dará cuenta de que le faltan objetos e intentará solicitarlos al servidor. 

Además también se incluye el nuevo comando git sparse-checkout que simplifica significativamente el trabajo y reduce el proceso de organización del trabajo con un repositorio incompleto.

El comando sparse-checkout permite establecer la lista de rutas, sin configurar manualmente así como mostrar la lista de rutas actual y habilitar o deshabilitar el checkout parcial.

Para optimizar el trabajo con repositorios muy grandes y listas de plantillas, se propone la configuración “git config core.sparseCheckoutCone“, que restringe las plantillas válidas (en lugar de plantillas arbitrarias .gitignore, puede especificar todas las rutas y si se deben extraer todos los archivos en un subdirectorio dado).

Por ejemplo, si el repositorio grande tiene el directorio “A/B/C” y todo el trabajo se concentra en el subdirectorio “C”, cuando el modo sparseCheckoutCone está activado, el comando “git sparse-checkout set A/B/C” extraerá completamente el contenido de “C”, pero de “A” y “B” extraerá solo las partes necesarias para trabajar con “C”.

En "git add", "git commit", "git reset"  otros comandos, se agrega una nueva opción: --pathspec-from-file“, que permite cargar una lista de rutas desde un archivo o flujo de entrada, en lugar de enumerarlas en la línea de comandos.

Se ha propuesto una implementación inicial del comando rediseñado git add -i, que le permite agregar contenido modificado de forma interactiva, reescrito de Perl a C. Una revisión similar del comando git add -p está en marcha.

El comando "git log --graph” fue refactorizado, formando una imagen ASCII del gráfico con el historial de cambios en el repositorio. El procesamiento nos permitió mejorar y simplificar significativamente la salida sin distorsionar la estructura de la historia, lo que, por ejemplo, resolvió el problema de sacar la imagen fuera del ancho de línea del terminal.

Mientras que para mejorar la legibilidad de los mensajes con parches enviados a listas de correo, se ha agregado la opción “git format-patch --cover-from-description subject“, al especificar qué, como tema de la carta de presentación para el conjunto de parches, se utiliza el primer párrafo del texto descriptivo de la rama.

Si quieres conocer más al respecto sobre este lanzamiento, puedes consultar el anuncio oficial en el siguiente enlace.