lanzamiento del sistema distribuido de control de versiones . Git es uno de los sistemas de control de versiones más populares, confiables y de alto rendimiento, que ofrece herramientas flexibles para el desarrollo no lineal, basadas en bifurcaciones y fusiones de ramas. Para garantizar la integridad del historial y la resistencia a los cambios retroactivos, se utiliza un hashing implícito de toda la historia anterior en cada commit, y también es posible certificar digitalmente firmas de desarrolladores para etiquetas y commits individuales.
En comparación con la versión anterior, la nueva versión incluye 504 cambios, preparados con la participación de 64 desarrolladores, de los cuales 12 participaron por primera vez en el desarrollo. :
- Se realizó la transición por defecto a del protocolo de comunicación de Git, que se utiliza para la conexión remota del cliente al servidor Git. La segunda versión del protocolo destaca por ofrecer la posibilidad de filtrar ramas y etiquetas en el servidor, devolviendo al cliente una lista reducida de enlaces. Anteriormente, al ejecutar cualquier comando de extracción, se enviaba al cliente la lista completa de enlaces en todo el repositorio, incluso cuando el cliente solo actualizaba una rama o verificaba la vigencia de su copia del repositorio. Otra novedad notable es la capacidad de añadir nuevas funcionalidades al protocolo a medida que surgen en las herramientas. El código del cliente sigue siendo compatible con el antiguo protocolo y puede seguir funcionando tanto con servidores nuevos como antiguos, retrocediendo automáticamente a la primera versión si el servidor no soporta la segunda.
- Al comando «git config» se añadió la opción «—show-scope», que facilita la identificación de dónde se definen ciertas configuraciones. Git permite definir configuraciones en diferentes lugares: en el repositorio (.git/info/config), en el directorio del usuario (~/.gitconfig), en el archivo de configuración del sistema (/etc/gitconfig), así como a través de opciones de la línea de comandos y variables de entorno. Al ejecutar «git config», es bastante difícil entender exactamente dónde está definida la configuración deseada. Para resolver esta tarea estaba disponible la opción «—show-origin», pero solo muestra la ruta al archivo donde está definida la configuración, lo cual es útil si se quiere editar el archivo, pero no ayuda si se requiere cambiar el valor a través de «git config» utilizando las opciones «—system», «—global» o «—local». La nueva opción «—show-scope» muestra el contexto de definición de las variables y puede usarse junto con «—show-origin»:
$ git —list —show-scope —show-origin
global file:/home/user/.gitconfig diff.interhunkcontext=1
global file:/home/user/.gitconfig push.default=current
[…]
local file:.git/config branch.master.remote=origin
local file:.git/config branch.master.merge=refs/heads/master$ git config —show-scope —get-regexp ‘diff.*’
global diff.statgraphwidth 35
local diff.colormoved plain$ git config —global —unset diff.statgraphwidth
- En la configuración de enlace Se permite el uso de máscaras en las URL. Cualquier configuración de HTTP y credenciales en Git pueden establecerse tanto para todas las conexiones (http.extraHeader, credential.helper) como para conexiones vinculadas a URL (credential.https://example.com.helper, credential.https://example.com.helper). Hasta ahora, se permitía el uso de máscaras como *.example.com solo para configuraciones de HTTP, pero no se admitía para la vinculación de credenciales. En Git 2.26, estas diferencias se han eliminado y, por ejemplo, para vincular un nombre de usuario a todos los subdominios, ahora se puede especificar:
[credential «https://*.example.com»]
username = ttaylorr
- Se ha continuado expandiendo el soporte experimental para la clonación parcial (partial clones), que permite transferir solo una parte de los datos y trabajar con una copia incompleta del repositorio. En esta nueva versión se ha añadido un nuevo comando «git sparse-checkout add», que permite añadir directorios individuales para aplicar la operación «checkout» solo a parte del árbol de trabajo, en lugar de enumerar todos esos directorios a la vez a través del comando «git sparse-checkout set» (se pueden añadir uno a uno, sin necesidad de volver a especificar toda la lista cada vez).
Por ejemplo, para clonar el repositorio git/git sin transferir blobs, restringiendo la verificación solo al directorio raíz de la copia de trabajo y etiquetando por separado para extraer los directorios «t» y «Documentation», se puede especificar:$ git clone —filter=blob:none —sparse git@github.com:git/git.git
$ cd git
$ git sparse-checkout init —cone$ git sparse-checkout add t
….
$ git sparse-checkout add Documentation
….
$ git sparse-checkout list
Documentation
t - Se ha aumentado notablemente el rendimiento del comando «git grep», utilizado para buscar tanto en el contenido actual del repositorio como en revisiones históricas. Para acelerar la búsqueda, se permitía escanear el contenido del árbol de trabajo utilizando múltiples hilos («git grep —threads»), pero la búsqueda en revisiones históricas era de un solo hilo. Ahora se ha eliminado esta limitación mediante la implementación de la posibilidad de paralelizar las operaciones de lectura del almacenamiento de objetos. Por defecto, el número de hilos se establece igual al número de núcleos de CPU, lo que en la mayoría de los casos ahora no requiere la opción explícita «—threads».
- Se ha añadido soporte para la autocompletación de la entrada de subcomandos, rutas, enlaces y otros argumentos del comando «git worktree», permitiendo trabajar con múltiples copias de trabajo del repositorio.
- Se añadió soporte para colores brillantes, para los cuales hay secuencias de escape ANSI disponibles. Por ejemplo, en la configuración de colores de resaltado «git config —color» o «git diff —color-moved» a través de la opción «—format» se puede especificar «%C(brightblue)» para un azul brillante.
- Se añadió una nueva versión del script , que proporciona integración con el mecanismo para acelerar el seguimiento de cambios en archivos y la aparición de nuevos archivos. Después de la actualización, git requiere un hook en el repositorio.
- Se añadieron optimizaciones para acelerar las operaciones de clonación parcial (partial clones), relacionadas con la aplicación de mapas de bits
(bitmap machinery) para evitar el escaneo completo de todos los objetos durante la filtración de los resultados. La verificación de blobs (—filter=blob:none y —filter=blob:limit=n) al clonar parcialmente ahora se realiza
de manera considerablemente más rápida. GitHub anunció la aplicación de parches con estas optimizaciones y soporte experimental para la clonación parcial. - El comando «git rebase» se trasladó a otro backend que utiliza por defecto el mecanismo ‘merge’ (anteriormente utilizado para «rebase -i») en lugar de ‘patch+apply’. En algunos detalles, los backends difieren, por ejemplo, después de continuar la operación tras resolver un conflicto (git rebase —continue) el nuevo backend sugiere editar el mensaje del commit, mientras que el antiguo simplemente usaba el mensaje anterior. Para recuperar el antiguo comportamiento se puede utilizar la opción «—apply» o configurar la variable ‘rebase.backend’ en ‘apply’.
- Un ejemplo de manejador de parámetros de autenticación, definido a través de .netrc, se ha simplificado para facilitar su uso inmediato.
- Se añadió la configuración gpg.minTrustLevel para establecer el nivel mínimo de confianza para diferentes elementos que realizan la verificación de la firma digital.
- En «git rm» y «git stash» se añadió la opción «—pathspec-from-file».
- Se han mejorado los conjuntos de pruebas en preparación para la transición al algoritmo de hash SHA-2 en lugar de SHA-1.
Fuente: opennet.ru
