Git 2.28 ya está aquí

La nueva version de Git 2.28 ya está aquí y llega para implementar algunos cambios relacionados con la terminología inclusiva en la cual semanas anteriores había expresado mediante redes sociales su apoyo y decisión de realizar cambios en la terminología que se ha manejado durante muchos años. 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, y proporciona herramientas de desarrollo no lineal flexibles basadas en versiones y fusiones.

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

Principales novedades de Git 2.28

De los cambios relacionados con la terminología se destaca la integración de la nueva configuración init.defaultBranch para permitir elegir un nombre de rama predeterminado arbitrario.

La configuración se ha agregado para proyectos cuyos desarrolladores quieran cambiar el término «master». Por su parte GitLab y Bitbucket han adoptado el valor predeterminado para usar la palabra «main» en lugar de «master» para las ramas principales.

En Git, como antes, ejecutar «git init» de forma predeterminada continúa creando la rama «master», pero este nombre ahora se puede cambiar. Por ejemplo, para cambiar el nombre de la rama inicial a «main o primary».

Para poder hacer esto se propone usar el comando:

git config –global init.defaultBranch main

Por otra parte podremos encontrar que se agregaron optimizaciones de rendimiento basadas en la apariencia en el formato de archivo de gráfico de compromiso, que se utiliza para optimizar el acceso a la información sobre los compromisos, el soporte para filtros Bloom, una estructura probabilística que permite una definición falsa de un elemento faltante, pero excluye la omisión de un elemento existente.

Esta estructura permite al usuario poder acelerar notablemente la búsqueda en el historial de cambios al usar los comandos «git log – » o «git blame».

En cuanto al protocolo «fetch/clone» se ha implementado la posibilidad de informar al cliente por el servidor acerca de la necesidad de descargar archivos de paquetes preparados previamente además de los datos de objetos empaquetados transmitidos.

También se destaca el trabajo continuó en la transición al algoritmo de hash SHA-256 en lugar de SHA-1.

Fuente: desdelinux