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, se han incluido 583 cambios en esta nueva versión, preparados por 84 desarrolladores, de los cuales 32 participaron en el desarrollo por primera vez. :
- Se está acercando a la estabilización y plena disponibilidad la posibilidad de clonación parcial (partial clones), que permite transferir solo parte de los datos y trabajar con una copia incompleta del repositorio. En una clonación normal, se copian todos los datos del repositorio, incluidas cada versión de cada archivo del historial de cambios. Para repositorios muy grandes, la copia de datos resulta en un aumento significativo del tráfico y del espacio en disco, incluso si al desarrollador solo le interesa un subconjunto de archivos. Para facilitar la obtención solo de una parte del árbol de trabajo de los textos fuente, en esta nueva versión se ha propuesto un comando experimental «sparse-checkout» y una nueva opción «—sparse» para el comando «clone».
Anteriormente, el proceso de clonación selectiva se realizaba mediante la especificación para filtrar el contenido innecesario y la opción «—no-checkout» para desactivar la recuperación de archivos faltantes. Después de esto, antes de realizar la operación de checkout, era necesario habilitar la configuración core.sparseCheckout y definir en el archivo .git/info/sparse-checkout la lista de patrones de rutas excluidas. Por ejemplo, para clonar sin blobs y prohibir la extracción de archivos de directorios anidados de profundidad 2 o más, se podía ejecutar:
git clone —filter=blob:none —no-checkout /tu/repositorio/aquí repo
$ cd repo
$ cat >.git/info/sparse-checkout <EOF
/*
!/*
EOF
$ git config core.sparseCheckout 1
$ git checkout .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í repo
git sparse-checkout set /ruta/a/verificar/El comando sparse-checkout permite establecer una lista de rutas para checkout (set) sin necesidad de configurar manualmente .git/info/sparse-checkout, así como mostrar la lista actual de rutas (list) y habilitar o deshabilitar checkout parciales (enable/disable).
Para optimizar el trabajo con repositorios muy grandes y listas de patrones, se ha propuesto la configuración ««, que limita las plantillas permitidas (en lugar de plantillas arbitrarias .gitignore, se puede especificar si se deben extraer todos los caminos y todos los archivos en un subdirectorio determinado). Por ejemplo, si en un repositorio grande hay un directorio «A/B/C» y todo el trabajo se centra en el subdirectorio «C», al activar el modo sparseCheckoutCone, el comando «git sparse-checkout set A/B/C» extraerá completamente el contenido de «C», pero de «A» y «B» solo extraerá las partes necesarias para trabajar con «C».
- Se han eliminado todas las menciones a la opción «—preserve-merges» de la documentación («git rebase -h»), que ha sido declarada obsoleta y en su lugar se debe utilizar para trasladar un conjunto de confirmaciones ««.
- Para mejorar la legibilidad de los mensajes con parches enviados a listas de correo, se ha añadido la opción «git format-patch —cover-from-description subject», que indica que el primer párrafo del texto de descripción de la rama se utilizará como tema de la carta de presentación para el conjunto de parches.
- Se ha implementado el soporte para la combinación de la comando «git apply —3way» y la configuración «merge.conflictStyle» («git apply» ahora tiene en cuenta el estilo de descripción de conflicto de merge.conflictStyle cuando es necesario resolver un conflicto tras intentar aplicar un archivo con un 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 con el soporte para la definición de límites de funciones en programas en lenguaje .
- En «git add», «git commit», «git reset» y otros comandos se ha añadido una nueva opción «—pathspec-from-file», que permite cargar una lista de rutas desde un archivo o estándar de entrada, en lugar de enumerarlas en la línea de comandos.
- Se ha resuelto un problema con la detección de renombramientos a nivel de directorios al registrar confirmaciones. La detección no funcionaba en caso de mover el contenido de un subdirectorio a la raíz del repositorio.
- Se ha propuesto una implementación inicial del comando rehecho «git add -i», que permite añadir contenido modificado en modo interactivo, reescrito de Perl a C. Se está realizando un rehacer similar para el comando «git add -p».
- Se ha hecho una refactorización del comando «git log —graph», que genera una imagen ASCII del gráfico con el historial de cambios en el repositorio. La renovación ha permitido mejorar y simplificar significativamente la salida sin distorsionar la estructura del historial, lo que, por ejemplo, resolvió el problema de que la imagen se desbordara más allá del ancho de la línea de la terminal.
- La opción «git log —format=..» permite cambiar el formato de la salida,
ampliada con el soporte de las banderas «l/L» para mostrar solo la parte del correo electrónico especificada antes del símbolo «@» (por ejemplo, útil cuando todos los desarrolladores tienen todos los correos en un mismo dominio). - Se ha añadido el subcomando «set-url» al comando «git submodule».
- Los conjuntos de pruebas han sido actualizados como parte de la preparación para la transición a
el algoritmo de hash SHA-2 en lugar de SHA-1.
Fuente: opennet.ru
