lanzamiento del sistema de control de código fuente distribuido . Git es uno de los sistemas de control de versiones más populares, fiables y de alto rendimiento que proporciona herramientas de desarrollo no lineal flexibles basadas en bifurcaciones y fusiones de bifurcaciones. Para garantizar la integridad del historial y la resistencia a los cambios retroactivos, se utiliza un hash implícito de todo el historial anterior en cada confirmación, también es posible verificar etiquetas individuales y confirmaciones con firmas digitales de los desarrolladores.
En comparación con la versión anterior, la nueva versión incluyó 583 cambios, elaborados con la participación de 84 desarrolladores, de los cuales 32 participaron en el desarrollo por primera vez. :
- La posibilidad de clonación parcial se acerca a la estabilización y la preparación total, lo que le permite transferir solo una parte de los datos y trabajar con una copia incompleta del repositorio. Un clon típico copia todos los datos del repositorio, incluidas todas las versiones de cada archivo en el historial de cambios. Para repositorios muy grandes, copiar datos genera un aumento significativo en el tráfico y el espacio en disco, incluso si el desarrollador solo está interesado en un subconjunto de archivos. Para que sea más fácil recuperar solo una parte del árbol de fuentes en funcionamiento, la nueva versión presenta un comando experimental "sparse-checkout" y una nueva opción "--sparse" para el comando "clonar".
Anteriormente, el proceso de clonación selectiva se realizaba mediante la tarea para filtrar contenido innecesario y la opción “—sin pago” para deshabilitar el llenado de archivos faltantes. Después de eso, antes de realizar la operación de pago, era necesario habilitar la configuración core.sparseCheckout y definir una lista de patrones de ruta excluidos en el archivo .git/info/sparse-checkout. Por ejemplo, para clonar sin blobs y evitar que se extraigan archivos de subdirectorios de profundidad 2 o más, puede ejecutar:
git clone --filter=blob:none --no-checkout /tu/repositorio/aquí repositorio
$ cd repositorio
$ gato >.git/info/sparse-checkout
/*
!/*
EOF
$ git config core.sparseCheckout 1
$ git pago.El nuevo comando "git sparse-checkout" simplifica enormemente el trabajo y reduce el proceso de organización del trabajo con un repositorio incompleto a los siguientes comandos:
git clone --filter=blob:none --sparse /tu/repositorio/aquí repositorio
git sparse-checkout set /ruta/a/compra/salidaEl comando sparse-checkout le permite establecer una lista de rutas para el pago (establecer) sin configurar manualmente .git/info/sparse-checkout, así como mostrar la lista actual de rutas (lista) y habilitar o deshabilitar pagos parciales (habilitar /desactivar).
Para optimizar el trabajo con repositorios muy grandes y listas de plantillas, el “", que limita los patrones permitidos (en lugar de patrones .gitignore arbitrarios, puede especificar si se deben verificar todas las rutas y todos los archivos en un subdirectorio determinado). Por ejemplo, si un repositorio grande tiene un directorio “A/B/C” y todo el trabajo se concentra en el subdirectorio “C”, entonces cuando habilita el modo sparseCheckoutCone, el comando “git sparse-checkout set A/B/ C” extraerá todo el contenido de “C”, pero de “A” y “B” extraerá sólo las partes necesarias para trabajar con “C”.
- De la documentación ("git rebase -h"), se eliminaron todas las referencias a la opción "--preserve-merges", que ha quedado obsoleta y debería usarse en su lugar para migrar un conjunto de confirmaciones.«.
- Para mejorar la legibilidad de los mensajes con parches enviados a listas de correo, se ha agregado la opción “git format-patch —cover-from-description asunto”, cuando se especifica, el primer párrafo del texto de descripción de la rama se utiliza como asunto del Carta de presentación para un conjunto de parches.
- Se implementó soporte para el uso combinado del comando “git apply -3way” y la configuración “merge.conflictStyle” (“git apply” ahora tiene en cuenta el estilo de descripción del conflicto de merge.conflictStyle cuando es necesario resolver el conflicto después de intentarlo para aplicar un archivo de parche al repositorio).
- El código de definición de funciones utilizado en operaciones como "git diff/grep --show-function/-function-context" se ha ampliado para admitir la definición de límites de funciones en programas de lenguaje. .
- Se ha agregado una nueva opción a "git add", "git commit", "git reset" y otros comandos: "-pathspec-from-file", que permite cargar una lista de rutas desde un archivo o flujo de entrada. , en lugar de enumerarlos en la línea de comando.
- Se ha resuelto el problema con la detección de cambios de nombre a nivel de directorio al escribir confirmaciones. La definición no funcionó si el contenido de un subdirectorio se movía a la raíz del repositorio.
- Se ha propuesto una implementación inicial del comando rediseñado “git add -i”, que le permite agregar contenido modificado de forma interactiva, reescrito de Perl a C. Se está llevando a cabo una revisión similar del comando "git add -p".
- Se ha refactorizado el comando “git log –graph”, generando una imagen ASCII de un gráfico con el historial de cambios en el repositorio. La reelaboración permitió mejorar y simplificar significativamente el resultado sin distorsionar la estructura de la historia, lo que, por ejemplo, resolvió el problema de que la imagen se extendiera más allá del ancho de la línea terminal.
- La opción "git log --format=.." le permite cambiar el formato de salida,
ampliado con soporte para los indicadores “l/L” para mostrar solo la parte de la dirección de correo electrónico indicada antes del símbolo “@” (por ejemplo, útil cuando todos los desarrolladores tienen todos los correos electrónicos en el mismo dominio). - Se agregó un subcomando "set-url" al comando "git submodule".
- Los kits de prueba se han actualizado en preparación para la transición a
algoritmo hash SHA-2 en lugar de SHA-1.
Fuente: opennet.ru