Git es uno de los sistemas de control de versiones más populares, fiables y de alto rendimiento, que proporciona herramientas de desarrollo no lineales flexibles basadas en ramificaciones y fusiones. Para garantizar la integridad del historial y la resistencia a los cambios «retroactivamente», se utiliza hash implícito de todo el historial anterior en cada confirmación, también es posible certificar con firmas digitales de los desarrolladores de etiquetas individuales y confirmaciones.
Hace poco fue anunciada su nueva version «Git 2.29.0» y en comparación con la versión anterior, se adoptaron 627 cambios en la nueva versión, elaborada con la participación de 89 desarrolladores, de los cuales 24 participaron en el desarrollo por primera vez.
Principales novedades de Git 2.29.0
En esta nueva version, incluye una opción experimental para usar el algoritmo hash SHA-256 en lugar del SHA-1 comprometido al escribir objetos en el repositorio. El hash se genera a partir del contenido de cada objeto en Git y es su identificador único. Cualquier cambio en los datos o encabezados de un objeto conduce a un cambio en su identificador. La ocurrencia de colisiones en el algoritmo hash teóricamente no excluye la formación de dos conjuntos de datos diferentes con un hash resultante.
Desafortunadamente, el algoritmo SHA-1 resultó no ser resistente a la formación artificial de colisiones, sino a la comisión de ataques reales a la sustitución de objetos en Git mediante la manipulación de colisiones SHA-1improbable, ya que para anular un objeto separado es necesario que el objeto anulado ya contenga un patrón de colisión, es decir un bloque arbitrario no se puede reemplazar.
Dado que cada colisión requiere enormes recursos para computar, se conocen las plantillas ya calculadas que conducen a colisiones y anteriormente en Git se agregó una verificación para los intentos de usarlas en objetos.
En esta etapa de desarrollo, solo puede elegir entre SHA-1 y SHA-256, pero hasta ahora no puede combinar diferentes hashes en un repositorio al mismo tiempo. Además, hasta ahora, ningún proveedor de Git, incluido GitHub, admite repositorios con hashes SHA-256. Hay planes para agregar funciones de portabilidad en el futuro.
Otro de los cambios de esta nueva version, es en el comando «git fetch» y «git push» a los que se agrega soporte para especificaciones exclusivas de enlaces (refspec), expande los derechos de enlaces coincidentes entre las ramas en los repositorios locales y externos. La exclusión de especificaciones de referencia puede ser útil en situaciones en las que no solo necesita seleccionar, sino también excluir ciertas ramas del mapeo. Por ejemplo, cuando era necesario verificar todas las ramas «refs/heads/*», excepto una «refs/heads/ref-to-exclude», antes era necesario especificar una lista completa, incluyendo explícitamente cada rama.
Se han agregado nuevos campos a «git for-each-ref» que se pueden especificar con la opción «-format», además del nombre, tipo e id del objeto. Por ejemplo, los campos agregados contenido: tamaño, asunto: desinfectar y modificador: corto para mostrar identificadores de objeto cortos. También se permite especificar múltiples argumentos «–merged» y «–no-merged» para filtrar enlaces.
Cuando ocurre un conflicto durante una operación «git merge», el encabezado del mensaje de confirmación ahora está entre corchetes para separar más explícitamente los datos de la confirmación de los mensajes de diagnóstico de Git.
Se agregó una nueva configuración «merge.renormalize», cuando se establecen, las operaciones de check-out y check-in se realizan para cada etapa de una combinación de tres vías.
Se revirtió la segunda versión del protocolo de comunicación Git, que se desactivó en la versión 2.27, y se usa cuando un cliente se conecta de forma remota a un servidor Git. El error que causaba problemas de estabilidad ha sido diagnosticado y corregido.
La opción «–first-parent» se ha agregado al comando «git bisect», que se usa para identificar la revisión en la que ocurrió un cambio regresivo, para cambiar la selección de confirmaciones que pasan entre la revisión de trabajo conocida y la revisión en la que ocurrió la manifestación del problema. Si especifica «–first-parent», solo se cuentan las confirmaciones en la rama fusionada, omitiendo la confirmación de fusión en sí.
Se mejoró la eficiencia del comando interno «git index-pack» que se usa al ejecutar «git push» o «git fetch» al paralelizar el empaquetado de un índice en sistemas de múltiples núcleos.
Se ha agregado la configuración «merge.suppressDest», que controla la adición de la frase «en $ dest» a los mensajes «Fusionar $ upstream en $ dest» emitidos cuando las ramas se fusionan (anteriormente, la frase «en $ dest» no se mostraba para la rama principal por defecto).
Se corrigió una vulnerabilidad en el backend «contrib/mw-to-git» (no construido por defecto) para empujar y recuperar datos de MediaWiki. El problema permitía organizar la ejecución del código al acceder a una instancia de MediaWiki que estaba bajo el control de un atacante.
Finalmente si quieres conocer mas al respecto, puedes consultar los detalles en el siguiente enlace.