{"id":141016,"date":"2025-08-19T11:11:54","date_gmt":"2025-08-19T09:11:54","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51"},"modified":"2025-08-19T11:11:54","modified_gmt":"2025-08-19T09:11:54","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-51","title":{"rendered":"Lanzamiento del sistema de control de versiones Git 2.51","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de dos meses de desarrollo, se presenta el lanzamiento del sistema de gesti\u00f3n distribuida de c\u00f3digos fuente Git 2.51. Git se caracteriza por su alta rendimiento y proporciona herramientas para el desarrollo no lineal, basadas en la ramificaci\u00f3n y la fusi\u00f3n de ramas. Para garantizar la integridad de la historia y la resistencia a cambios \"retroactivos\", se utiliza una hash impl\u00edcita de toda la historia previa en cada commit, as\u00ed como la certificaci\u00f3n por firmas digitales de los desarrolladores de etiquetas y commits individuales. El c\u00f3digo de Git se distribuye bajo la licencia GPLv2+. <\/p>\n
Comparado con la versi\u00f3n anterior, en la nueva versi\u00f3n se han aceptado 506 cambios, preparados con la participaci\u00f3n de 91 desarrolladores (21 de los cuales participaron en el desarrollo de Git por primera vez). Las principales novedades (1, 2, 3): <\/p>\n
\n
Se ha mejorado el rendimiento de los comandos \"git push\" y \"git fetch\" en repositorios con un gran n\u00famero de referencias. La aceleraci\u00f3n se ha logrado mediante la actualizaci\u00f3n de referencias en modo por lotes, en el que varias referencias se procesan en una sola transacci\u00f3n, en lugar de crear una transacci\u00f3n separada para actualizar cada referencia. La optimizaci\u00f3n ha aumentado significativamente la velocidad de funcionamiento del backend \"reftable\", que ahora supera en rendimiento al backend \"files\". Por ejemplo, en un repositorio de prueba con 10,000 referencias, el rendimiento de \"git fetch\" al usar el backend \"reftable\" se increment\u00f3 22 veces, mientras que al usar el backend \"files\" aument\u00f3 1.25 veces. Para \"git push\", el aumento fue de 18 y 1.21 veces, respectivamente.\n
Se ha propuesto un nuevo m\u00e9todo de empaquetado en archivos pack de partes del repositorio que no est\u00e1n relacionadas con el seguimiento de objetos inalcanzables, a los cuales no hay referencias en el repositorio (no mencionados por ramas o etiquetas). La informaci\u00f3n sobre objetos inalcanzables se almacena en archivos pack separados (\"cruft packs\"), lo que llev\u00f3 a la necesidad de reflejarlos en \u00edndices de m\u00faltiples paquetes MIDX (multi-pack index) para abarcar objetos que originalmente eran inalcanzables y se almacenaban solo en el paquete cruft, pero que luego se volvieron alcanzables tras un commit que los referenciaba.\n
En la nueva versi\u00f3n, al reempaquetar archivos pack se asegura la conservaci\u00f3n de copias adicionales de objetos accesibles, que solo se almacenan en archivos cruft. Este cambio garantiza que en el conjunto de archivos pack utilizados para almacenar objetos accesibles no haya objetos que referencien otros objetos almacenados fuera de este conjunto. Para excluir del \u00edndice multipack (MIDX) el contenido inaccesible de archivos cruft, se ha propuesto la configuraci\u00f3n \u00abrepack.MIDXMustContainCruft\u00bb, que permite reducir en gran medida el tama\u00f1o de tales \u00edndices. Activar esta opci\u00f3n en el repositorio de GitHub ha permitido reducir el tama\u00f1o de los \u00edndices MIDX en un 38%, acelerar la escritura en \u00edndices MIDX en un 35% y mejorar el rendimiento de lectura en un 5%. <\/p>\n
Se ha a\u00f1adido a la herramienta \u00abgit pack-objects\u00bb la opci\u00f3n \u00ab--path-walk\u00bb, que incluye un nuevo m\u00e9todo para recopilar informaci\u00f3n sobre los objetos al reempaquetar archivos pack. En lugar de recorrer los objetos en el orden de revisiones, al utilizar el modo \u00ab--path-walk\u00bb, los objetos se recorren a trav\u00e9s de las rutas de los archivos, lo que permite empaquetar simult\u00e1neamente todos los objetos con la misma ruta de archivo. Este enfoque elimina la heur\u00edstica que utiliza el hash para determinar la relaci\u00f3n de un objeto con su ruta de archivo, as\u00ed como evita la clasificaci\u00f3n de objetos antes de empaquetarlos. Al usar el modo \u00ab--path-walk\u00bb, el tama\u00f1o de los archivos pack generados es significativamente menor que al agrupar objetos mediante hashes.\n
Se ha determinado el formato para intercambiar los estados guardados del \u00e1rbol de trabajo y los \u00edndices en el repositorio, creados mediante el comando \u00abgit stash\u00bb. El nuevo formato permite codificar los cambios guardados (registros de stash) como una secuencia de commits. Para la importaci\u00f3n y exportaci\u00f3n se han propuesto los subcomandos \u00abgit stash import\u00bb y \u00abgit stash export\u00bb, que se pueden usar para transferir estados guardados de un sistema a otro y realizar operaciones push o pull con estos estados como si fueran ramas o etiquetas normales. git stash export --to-ref refs\/stashes\/my-stash git push origin refs\/stashes\/my-stash \u2026 git fetch origin '+refs\/stashes\/*:refs\/stashes\/*' git stash import refs\/stashes\/my-stash\n
En el comando «git cat-file», que muestra el contenido de los objetos especificados, se ha implementado la capacidad de mostrar informaci\u00f3n sobre objetos que faltan (por ejemplo, debido a la corrupci\u00f3n del repositorio) y subm\u00f3dulos cuando se utilizan las opciones «—batch» y «—batch-check». Anteriormente, al especificar la ruta a un subm\u00f3dulo, el comando «git cat-file —batch-check» mostraba «missing», mientras que ahora mostrar\u00e1 el identificador del objeto.\n
En el comando «git log» se han implementado optimizaciones basadas en filtros de Bloom para acelerar la b\u00fasqueda en el historial de cambios al especificar filtros con m\u00faltiples rutas de archivos, por ejemplo, «git log — path\/to\/a path\/to\/b».\n
Se han estabilizado los comandos «git switch» y «git restore», que desde 2019 se han considerado experimentales. Estos comandos se presentan como equivalentes modernos de «git checkout», separando las capacidades poco relacionadas de este comando, como la manipulaci\u00f3n de ramas (cambio y creaci\u00f3n) y la restauraci\u00f3n de archivos en el directorio de trabajo.\n
El comando «git whatchanged», equivalente a «git log —raw», ha sido declarado obsoleto y se prev\u00e9 su eliminaci\u00f3n en la versi\u00f3n 3.0 de Git.\n
Se ha agregado la opci\u00f3n «—start-after» al comando «git for-each-ref», que puede usarse junto con la opci\u00f3n «—count» para organizar la salida paginada.\n
Se ha agregado la opci\u00f3n «—compact-summary» a los comandos «git merge» y «git pull» para utilizar un formato compacto de resumen de los cambios en lugar del formato diffstat.\n
Se ha permitido el uso de la palabra clave «bool» en la base de c\u00f3digo de Git, introducida en el est\u00e1ndar C99. Tambi\u00e9n se han documentado algunas caracter\u00edsticas de C99 que se utilizan experimentalmente en Git (por ejemplo, se prev\u00e9 permitir el uso de construcciones «(struct foo){ .member = value };» a mediados de 2026). Un compilador compatible con C99 es obligatorio para Git desde 2021, pero las caracter\u00edsticas de la especificaci\u00f3n C99 se implementan con mucha cautela para mantener la compatibilidad con compiladores que solo soportan parcialmente este est\u00e1ndar.\n
Se han realizado cambios en las reglas para la aceptaci\u00f3n de parches que permiten enviar parches bajo un seud\u00f3nimo, y no solo con el verdadero nombre del desarrollador. Este cambio se alinea con las reglas de aceptaci\u00f3n de parches en el n\u00facleo de Linux.\n
Se ha actualizado la lista de cambios que afectan la compatibilidad, que se aplicar\u00e1n en la rama Git 3.0. Entre los cambios significativos en el pr\u00f3ximo lanzamiento de Git 3.0 se encuentra la transici\u00f3n por defecto a identificadores de objetos basados en el algoritmo de hash SHA-256 al inicializar nuevos repositorios y el uso del formato \u00abreftable\u00bb para almacenar en el repositorio las referencias a ramas y etiquetas (se ha implementado un almacenamiento en bloques del proyecto JGit, optimizado para almacenar un n\u00famero muy grande de referencias). <\/ul>\n