{"id":148781,"date":"2025-11-18T23:12:24","date_gmt":"2025-11-18T21:12:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52"},"modified":"2025-11-18T23:12:24","modified_gmt":"2025-11-18T21:12:24","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-52","title":{"rendered":"Lanzamiento del sistema de control de versiones Git 2.52","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Tras tres meses de desarrollo, se presenta la versi\u00f3n del sistema distribuido de gesti\u00f3n de c\u00f3digo fuente Git 2.52. Git destaca por su alta eficiencia y ofrece herramientas para el desarrollo no lineal, basadas en bifurcaciones y fusiones de ramas. Para garantizar la integridad del historial y la resistencia a cambios 'retroactivos', se utiliza un hash impl\u00edcito de toda la historia anterior en cada confirmaci\u00f3n, as\u00ed como la certificaci\u00f3n mediante firmas digitales de los desarrolladores en etiquetas y confirmaciones espec\u00edficas. El c\u00f3digo de Git se distribuye bajo la licencia GPLv2+. <\/p>\n
En comparaci\u00f3n con la versi\u00f3n anterior, en la nueva versi\u00f3n se han incorporado 637 cambios, preparados con la participaci\u00f3n de 94 desarrolladores (33 participaron por primera vez en el desarrollo de Git). Principales novedades (1, 2, 3): <\/p>\n
\n
Se ha a\u00f1adido el comando 'git last-modified' para mostrar una lista de archivos en la revisi\u00f3n especificada y las confirmaciones a trav\u00e9s de las cuales se realizaron los \u00faltimos cambios en cada uno de estos archivos. $ git last-modified HEAD b56f6dcd7b4c90192018e848d0810f091d092913 test.h 29330ae4b820147c98e723399e9438c8bee60a8a test1.c 573ad8917beb99dc643b6e7f5c117a294384a575 test2.c\n
Se ha a\u00f1adido el comando 'git repo' para realizar acciones relacionadas con la extracci\u00f3n de informaci\u00f3n de un repositorio. Se han propuesto dos subcomandos: 'git repo info' y 'git repo structure', que proporcionan informaci\u00f3n sobre la configuraci\u00f3n del repositorio y detalles sobre la estructura del repositorio (por ejemplo, se puede averiguar el n\u00famero de referencias y objetos en el repositorio). $ git repo info object.format references.format object.format=sha1 references.format=reftable $ git repo structure | Estructura del repositorio | Valor | | -------------------------- | ------- | | * Referencias | | | * Conteo | 1983 | | * Ramas | 4 | | * Etiquetas | 1125 | | * Remotos | 854 | | * Otros | 0 | | | | * Objetos alcanzables | | | * Conteo | 518955 | | * Confirmaciones | 77469 | | * \u00c1rboles | 188865 | | * Blobs | 251631 | | * Etiquetas | 990 |\n
Se han a\u00f1adido tres subcomandos al comando 'git refs', unificando operaciones de bajo nivel dispares y superpuestas sobre referencias (git for-each-ref, git show-ref, git update-ref y git pack-refs):\n
\n
'git refs optimize' \u2014 optimizaci\u00f3n del backend de almacenamiento de referencias (similar a 'git pack-refs').\n
'git refs list' \u2014 muestra una lista de todas las referencias (similar a 'git for-each-ref' o 'git show-ref').\n
'git refs exists' \u2014 verifica la existencia de una referencia (equivalente a 'git show-ref --exists'). <\/ul>\n
El formato para exportar o importar el historial de commits se ha ampliado con la capacidad de trabajar con firmas criptogr\u00e1ficas, utilizando identificadores de objetos basados en el algoritmo SHA-1 y SHA-256. En el comando «git fast-import» se ha implementado soporte para el manejo de etiquetas firmadas de manera similar a los commits firmados. Se han agregado las opciones «—signed-commits=<modo>» y «—signed-tags=<modo>» para controlar el manejo de commits y etiquetas firmadas durante la importaci\u00f3n (el modo puede aceptar valores como verbatim, warn-verbatim, warn-stri, strip o abort).\n
El comando «git maintenance» ha a\u00f1adido soporte para una nueva estrategia «geometric» («git config set maintenance.strategy geometric»), que permite reducir el tiempo de mantenimiento de grandes monorepositorios. En comparaci\u00f3n con la estrategia anterior, que utilizaba la l\u00f3gica del comando «git gc», la nueva estrategia evita la recompresi\u00f3n de todos los objetos y excluye operaciones excesivamente exigentes en recursos, como la fusi\u00f3n de todos los archivos de paquete (la combinaci\u00f3n se realiza en partes y sin limpiar objetos eliminados, cuando es posible).\n
Se ha a\u00f1adido el comando «git sparse-checkout clean» para simplificar la recuperaci\u00f3n del estado del directorio de trabajo, eliminando archivos que no cumplen con la nueva definici\u00f3n de sparse-checkout y que no deber\u00edan estar presentes en la copia local de acuerdo con los par\u00e1metros actuales de sparse-checkout.\n
Para eliminar complicaciones de la base de c\u00f3digo y simplificar el mantenimiento, se ha realizado una refactorizaci\u00f3n para reducir el uso de la variable global the_repository.\n
Se ha ampliado el uso de los filtros de Bloom, una estructura probabil\u00edstica para comprobar la pertenencia a un conjunto, que permite una falsa determinaci\u00f3n de un elemento ausente, pero excluye la omisi\u00f3n de un elemento existente. Los filtros de Bloom ahora se utilizan para acelerar la b\u00fasqueda en el historial de cambios al especificar m\u00e1scaras en las rutas de archivo, por ejemplo, «foo\/bar\/*\/baz».\n
El rendimiento del comando «git describe» ha aumentado hasta un 30%, gracias al uso de colas de prioridad. En «git remote rename» se han acelerado las operaciones de renombrado de referencias. En «git ls-files» se ha ampliado el uso de \u00edndices. Se ha notado una mejora significativa en la velocidad del comando «git log -L», gracias a la eliminaci\u00f3n de comparaciones triviales de tres niveles durante el manejo de fusiones de commits. Se han realizado optimizaciones en la biblioteca xdiff.\n
Se ha proporcionado la opci\u00f3n de utilizar implementaciones en el lenguaje Rust para algunas funciones internas, como la codificaci\u00f3n y decodificaci\u00f3n de valores enteros de longitud variable. Por defecto, el c\u00f3digo en Rust no se utiliza y su inclusi\u00f3n requiere la especificaci\u00f3n de la bandera de compilaci\u00f3n WITH_RUST. En el futuro, se anticipa una reescritura en Rust de componentes internos m\u00e1s significativos de Git y la adici\u00f3n de Rust a las dependencias de compilaci\u00f3n obligatorias en Git 3.0.\n
Se ha actualizado la lista de cambios que afectan la compatibilidad y que se aplicar\u00e1n en la rama Git 3.0. En Git 3.0, se ha decidido cambiar la configuraci\u00f3n init.defaultBranch al valor predeterminado de \"main\", es decir, en los repositorios creados con el comando \"git init\", la rama predeterminada se nombrar\u00e1 \"main\" y no \"master\". Tambi\u00e9n se se\u00f1ala la transici\u00f3n por defecto a identificadores de objetos basados en el algoritmo de hash SHA-256 al inicializar nuevos repositorios. Para facilitar la portabilidad entre repositorios con identificadores de objetos basados en hashes SHA-1 y SHA-256, se proporciona la capacidad de realizar operaciones de push y pull desde un repositorio que utiliza un algoritmo de hash diferente. <\/ul>\n