{"id":103093,"date":"2022-01-25T15:36:40","date_gmt":"2022-01-25T13:36:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35"},"modified":"2022-01-25T15:36:40","modified_gmt":"2022-01-25T13:36:40","slug":"vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-sistemy-upravleniya-ishodnymi-tekstami-git-2-35","title":{"rendered":"Lanzamiento del sistema de control de versiones Git 2.35","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de dos meses de desarrollo, se ha lanzado la versi\u00f3n 2.35 del sistema distribuido de gesti\u00f3n de c\u00f3digo fuente Git. Git es uno de los sistemas de control de versiones m\u00e1s populares, confiables y de alto rendimiento, que ofrece herramientas flexibles para el desarrollo no lineal, basadas en ramas y fusiones. Para garantizar la integridad del historial y la resistencia a los cambios \"retroactivos\", se utiliza un hashing impl\u00edcito de todo el historial anterior en cada commit, tambi\u00e9n es posible verificar las firmas digitales de los desarrolladores en etiquetas y commits individuales. <\/p>\n
En comparaci\u00f3n con la versi\u00f3n anterior, en esta nueva versi\u00f3n se han incorporado 494 cambios, preparados con la participaci\u00f3n de 93 desarrolladores, de los cuales 35 participaron por primera vez en el desarrollo. Las principales novedades son: <\/p>\n
\n
Se han ampliado las capacidades del uso de claves SSH para firmar objetos de Git. Para diferenciar la duraci\u00f3n de varias claves, se ha a\u00f1adido soporte para las directivas de OpenSSH \"valid-before\" y \"valid-after\", mediante las cuales se puede garantizar un funcionamiento correcto con las firmas despu\u00e9s de la rotaci\u00f3n de la clave de uno de los desarrolladores. Anteriormente, hab\u00eda un problema con la separaci\u00f3n de las firmas de la clave antigua y la nueva: si se eliminaba la antigua, no se pod\u00eda verificar las firmas realizadas con ella, y si se manten\u00eda, se pod\u00eda seguir creando nuevas firmas con la antigua clave, que ya hab\u00eda sido sustituida por una nueva. Con valid-before y valid-after, se puede dividir la validez de las claves seg\u00fan el momento de creaci\u00f3n de la firma.\n
En la configuraci\u00f3n merge.conflictStyle, que permite elegir el modo de presentaci\u00f3n de la informaci\u00f3n sobre conflictos durante la fusi\u00f3n, se ha a\u00f1adido soporte para el modo \"zdiff3\", que mueve fuera del \u00e1rea de conflicto todas las l\u00edneas de contexto especificadas al principio o al final del conflicto, lo que permite lograr una presentaci\u00f3n m\u00e1s compacta de la informaci\u00f3n.\n
Se ha a\u00f1adido el modo \"--staged\" al comando \"git stash\", que permite ocultar solo los cambios a\u00f1adidos al \u00edndice, por ejemplo, en situaciones en las que es necesario aplazar temporalmente parte de los cambios complejos para poder agregar primero lo que ya est\u00e1 listo y resolver lo dem\u00e1s m\u00e1s tarde. Este modo es similar al comando \"git commit\", que registra solo los cambios incluidos en el \u00edndice, pero en lugar de crear un nuevo commit, en \"git stash --staged\" el resultado se guarda en el \u00e1rea temporal stash. Una vez que los cambios son necesarios, se pueden recuperar con el comando \"git stash pop\".\n
Se ha a\u00f1adido un nuevo especificador de formato al comando «git log», permitiendo combinar la salida de «git log» con el resultado de la ejecuci\u00f3n del comando «git describe». Los par\u00e1metros para «git describe» se especifican directamente dentro del especificador («—format=%(describe:match=<foo>,exclude=<bar>)»), en el que tambi\u00e9n se pueden incluir etiquetas abreviadas («—format=%(describe:tags=<bool>)») y ajustar el n\u00famero de caracteres hexadecimales para la identificaci\u00f3n de objetos («—format=%(describe:abbrev=<n>)»). Por ejemplo, para mostrar los 8 \u00faltimos commits, cuyos tags no tienen etiqueta de candidato a lanzamiento, y especificar identificadores de 8 caracteres, se puede usar el comando: $ git log -8 —format=’%(describe:exclude=*-rc*,abbrev=13)’ v2.34.1-646-gaf4e5f569bc89 v2.34.1-644-g0330edb239c24 v2.33.1-641-g15f002812f858 v2.34.1-643-g2b95d94b056ab v2.34.1-642-gb56bd95bbc8f7 v2.34.1-203-gffb9f2980902d v2.34.1-640-gdf3c41adeb212 v2.34.1-639-g36b65715a4132\n
En la configuraci\u00f3n user.signingKey se ha implementado el soporte para nuevos tipos de claves, que no se limitan al tipo «ssh-» y a la especificaci\u00f3n de la ruta completa del archivo de la clave. Los tipos alternativos se especifican mediante el prefijo «key::», por ejemplo, «key::ecdsa-sha2-nistp256» para claves ECDSA.\n
Se ha incrementado notablemente la velocidad de generaci\u00f3n de la lista de cambios en el modo «—histogram», as\u00ed como al usar la opci\u00f3n «—color-moved-ws», que controla el resaltado de espacios en el diff de colores.\n
En el comando «git jump», que se utiliza para proporcionar a Vim informaci\u00f3n sobre transiciones precisas a una posici\u00f3n deseada en el archivo durante el an\u00e1lisis de conflictos de fusi\u00f3n, la revisi\u00f3n de diferencias o la ejecuci\u00f3n de una b\u00fasqueda, se ha a\u00f1adido la posibilidad de restringir los conflictos de fusi\u00f3n abarcados. Por ejemplo, para limitar operaciones solo al directorio «foo», se puede especificar «git jump merge — foo», y para excluir el directorio «Documentation» de la operaci\u00f3n — «git jump merge ‘:^Documentation'».\n
Se ha trabajado en la estandarizaci\u00f3n del uso del tipo «size_t» en lugar de «unsigned long» para valores que representan el tama\u00f1o de objetos, lo que ha permitido la aplicaci\u00f3n de filtros «clean» y «smudge» a archivos de m\u00e1s de 4 GB en todas las plataformas, incluidas las plataformas con un modelo de datos LLP64, donde el tipo «unsigned long» est\u00e1 limitado a 4 bytes.\n
Se ha a\u00f1adido la opci\u00f3n «—empty=(stop|drop|keep)» al comando «git am», lo que permite seleccionar el comportamiento para los correos vac\u00edos sin parches al analizar parches desde el buz\u00f3n. El valor «stop» finalizar\u00e1 toda la operaci\u00f3n de aplicaci\u00f3n de parches, «drop» omitir\u00e1 el parche vac\u00edo y «keep» crear\u00e1 un commit vac\u00edo.\n
Los comandos «git reset», «git diff», «git blame», «git fetch», «git pull» y «git ls-files» ahora admiten \u00edndices parciales (sparse index), lo que permite mejorar el rendimiento y ahorrar espacio en los repositorios donde se llevan a cabo operaciones de clonaci\u00f3n parcial (sparse-checkout).\n
Se ha declarado obsoleto el comando «git sparse-checkout init», en su lugar se debe utilizar «git sparse-checkout set».\n
Se ha a\u00f1adido una implementaci\u00f3n inicial de un nuevo backend «reftable» para almacenar referencias, como ramas y etiquetas, en el repositorio. Este nuevo backend utiliza un almacenamiento basado en bloques, utilizado por el proyecto JGit y optimizado para almacenar un n\u00famero muy grande de referencias. El backend a\u00fan no est\u00e1 integrado con el sistema de referencias (refs) y no est\u00e1 listo para su uso pr\u00e1ctico.\n
La paleta de colores del comando «git grep» se ha alineado con la utilidad GNU grep. <\/ul>\n