Banner de git 2.44
La nueva versión de Git 2.44, ya fue liberada y llega después de tres meses de desarrollo e incluye 503 cambios en comparación con la versión anterior, y estos cambios fueron preparados con la colaboración de 85 desarrolladores, de los cuales 34 participaron en el desarrollo por primera vez.
Para quienes desconocen de Git, deben saber que es conocido como uno de los sistemas de control de versiones más populares, confiables y de alto rendimiento, ofreciendo herramientas flexibles de desarrollo no lineal basadas en ramificaciones y fusiones. Para mantener la integridad del historial y prevenir cambios retroactivos, Git utiliza un hash implícito de todo el historial anterior en cada confirmación.
Principales novedades de Git 2.44
En esta nueva versión de Git 2.44, una de las novedades más importantes es el nuevo soporte para la reutilización de objetos en múltiples paquetes. Esta optimización permite a Git aprovechar la reutilización de objetos en varios paquetes, eliminando la necesidad de empaquetar un repositorio en un solo paquete. Con esta mejora, Git puede generar paquetes de forma más eficiente, lo que resulta en una mejor velocidad y rendimiento durante las operaciones de envío y extracción desde y hacia repositorios remotos. A partir de la versión 2.44, Git puede manejar la reutilización de objetos en múltiples archivos de paquete sin la necesidad de volver a empaquetar el repositorio en un solo archivo de paquete.
Además de ello, la introducción de «git replay» ofrece una alternativa eficaz a git rebase, y se puede usar para recrear el historial en un servidor sin un árbol de trabajo (un repositorio simple que no contiene un árbol de trabajo), procesar múltiples ramas simultáneamente, realizar una operación de rebase en ramas, diferente de las recuperadas actualmente, o simplemente para acelerar las operaciones de fusión. Git replay ofrece mejoras significativas de rendimiento, especialmente en operaciones de fusión y rebase en repositorios de gran tamaño.
Con Git 2.44, la opción –autosquash ahora se puede usar para operaciones de cambio de base en modo no interactivo. Esta funcionalidad permite aplicar automáticamente confirmaciones fixup! o squash! en sus ubicaciones correspondientes sin la necesidad de inspeccionar manualmente la lista de tareas pendientes.
Otro de los aspectos destacados, son las nuevas funcionalidades y mejoras significativas. Ahora, los comandos «git add» y «git stash» admiten los atributos de ruta «
attr:…)», que se configuran de manera similar al comando «git show». Por ejemplo, «git add ‘attr:~binary)'» puede utilizarse para agregar todos los archivos de texto (no binarios) al índice. Además, se ha introducido el atributo «builtin_objectmode» para filtrar rutas de archivos por derechos de acceso. Por ejemplo, «git add ‘attr:builtin_objectmode=100755)'» puede utilizarse para agregar todos los ejecutables al índice.De los demás cambios que se destacan:
- Se agregó soporte para el sistema de integración continua GitLab CI.
- Se agregó la opción «–diff-algorithm» al comando «git merge-file» para seleccionar un algoritmo alternativo para evaluar las diferencias entre archivos.
- Se agregó soporte para actualizar tokens OAuth al backend de administración de credenciales wincred, de manera similar a cómo se implementa en los backends credential-cache y credential-libsecret.
- «git fetch» ha agregado soporte para la opción de configuración «fetch.all«, que se manejará de manera similar a agregar la opción «–all» en la línea de comando.
- Se ha añadido la opción «–ignore-other-worktrees» para habilitar la actualización y el check-out de ramas que utilizan un árbol de trabajo diferente. Esto restaura el comportamiento anterior del comando «git checkout -B».
- Ahora es posible establecer esta configuración en «true» para eliminar la instrucción «Disable this message with…» que ocupaba espacio en la pantalla al mostrar sugerencias. Esto mejora la experiencia del usuario al eliminar elementos innecesarios de la salida del comando.
- Se ha optimizado la ejecución de este comando con la opción «–no-sort». Anteriormente, incluso al especificar «–no-sort«, la ordenación todavía se aplicaba en orden alfabético. Ahora, después de las optimizaciones, el uso de «–no-sort» acelera «git for-each-ref» en aproximadamente un 20% en repositorios con una gran cantidad de referencias.
Finalmente si estás interesado en conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...