Hace poco se dio a conocer el lanzamiento de la nueva versión sistema de control de código fuente distribuido Git 2.38, que en comparación con la versión anterior, se aceptaron 699 cambios en la nueva versión, preparada con la participación de 92 desarrolladores, de los cuales 24 participaron en el desarrollo por primera vez.

Para quienes desconocen de Git, deben saber que este es uno de los sistemas de control de versiones más populares, fiables y de alto rendimiento que proporciona herramientas de desarrollo no lineal flexibles basadas en bifurcaciones y fusiones de bifurcaciones.

Para garantizar la integridad del historial y la resistencia a los cambios «backdating», se utiliza el hashing implícito de todo el historial anterior en cada confirmación, también es posible verificar las firmas digitales de los desarrolladores de etiquetas y confirmaciones individuales.

Principales novedades de Git 2.38

En esta nueva versión que se presenta de Git 2.38 se destaca que se incluye la utilidad «scalar» desarrollada por Microsoft para la gestión de grandes repositorios. La utilidad se escribió originalmente en C#, pero se incluye una versión C modificada en git. La nueva utilidad difiere del comando git al incluir funciones y configuraciones adicionales predeterminadas que afectan el rendimiento cuando se trabaja con repositorios muy grandes.

Por ejemplo, cuando se usa scalar, se aplica lo siguiente:

• Clonación parcial para trabajar con una copia incompleta del repositorio.
• Mecanismo integrado de seguimiento de cambios en el sistema de archivos  (FSMonitor), que elimina la necesidad de enumerar todo el directorio de trabajo.
• Índices que cubren objetos en diferentes paquetes de archivos ( multi-paquete).
• Archivos de gráfico de confirmación con un índice de gráfico de confirmación utilizado para optimizar el acceso a la información de confirmación.
• Trabajo periódico en segundo plano para mantener la estructura óptima del repositorio en segundo plano sin bloquear la sesión interactiva (una vez por hora, se realiza trabajo para obtener objetos nuevos del repositorio remoto y actualizar el archivo con el gráfico de confirmación, y el proceso de empaquetado del el repositorio se inicia todas las noches).
• Un modo «sparseCheckoutCone» que restringe los patrones válidos en la clonación parcial.

Otro de los cambios que se presenta en esta nueva versión de Git 2.38 es la opción «–update-refs» al comando «git rebase» para actualizar las ramas dependientes que se cruzan con las ramas reubicadas, de modo que no tenga que pagar manualmente cada rama dependiente para cambiar a la confirmación deseada.

Tambien se destaca que el formato de archivo de mapa de bits se ha optimizado para trabajar con repositorios grandes: se ha agregado una tabla de índice opcional con una lista de confirmaciones seleccionadas y sus compensaciones.

Ademas de ello, podremos encontrar que en el comando «git merge-tree» implementa un nuevo modo en el que, en función de dos confirmaciones específicas, se calcula un árbol con el resultado de la combinación, como si se fusionaran los historiales de estas confirmaciones.

Se agregó la configuración «safe.barerepository» para controlar si los repositorios que no contienen un árbol de trabajo, se pueden colocar dentro de otros repositorios de git. Cuando se establece en «explicit», los repositorios desnudos ubicados en el directorio superior solo podrán funcionar. Para poder colocar repositorios desnudos en subdirectorios, se debe usar el valor «todos».

De los demás cambios que se destacan de esta nueva version:

• Se agregó la opción «-m» («–max-count») al comando «git grep», que es similar a la opción grep de GNU del mismo nombre y le permite limitar la cantidad de resultados de coincidencias.
• El comando «ls-files» implementa la opción «–format» para personalizar los campos de salida (por ejemplo, puede habilitar la salida del nombre del objeto, modos, etc.).
• En «git cat-file», al mostrar el contenido de los objetos, se implementa la capacidad de tener en cuenta los enlaces de los autores al correo electrónico, especificados en el archivo de mapa de correo.
• Comando «git rm» hecho compatible con índices parciales.
• Se mejoró el comportamiento del comando «git mv A B» al mover un archivo desde un espacio de trabajo con índices parciales en modo «cono» a un área exterior donde no se aplica este modo.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.