Administración y almacenamiento de archivos grandes en Git

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Git ayuda a mantener la superficie del código fuente pequeña porque las diferencias entre las versiones se seleccionan fácilmente y el código se comprime fácilmente. Los archivos grandes que no se comprimen bien y que cambian completamente entre versiones (como archivos binarios) presentan problemas cuando se almacenan en los repositorios de Git. El rendimiento rápido de Git proviene de su capacidad de abordar y cambiar a todas las versiones de un archivo desde su almacenamiento local.

Si tiene archivos grandes e indiffables en el repositorio (como archivos binarios), mantendrá una copia completa de esos archivos en el repositorio cada vez que confirme un cambio en ellos. Si existen muchas versiones de estos archivos en el repositorio, aumentan considerablemente el tiempo de des check out, branch, fetch y clonen el código.

¿Qué tipos de archivos debe almacenar en Git?

Confirmar código fuente, no dependencias

A medida que el equipo trabaja con editores y herramientas para crear y actualizar archivos, debe colocar estos archivos en Git para que el equipo pueda disfrutar de las ventajas del flujo de trabajo de Git. No confirme otros tipos de archivos en el repositorio: por ejemplo, archivos DLL, archivos de biblioteca y otras dependencias de las que el equipo no crea, pero el código depende. Entregue estos archivos a través de la administración de paquetes a los sistemas.

La administración de paquetes agrupa las dependencias e instala los archivos en el sistema al implementar el paquete. Los paquetes tienen versiones para asegurarse de que el código probado en un entorno se ejecuta igual en otro entorno, siempre que los entornos tengan los mismos paquetes instalados.

No confirmar salidas

No confirme los archivos binarios, los registros, la salida de seguimiento ni los datos de diagnóstico de las compilaciones y pruebas. Estas son salidas del código, no del propio código fuente. Comparta registros e información de seguimiento con su equipo a través de herramientas de seguimiento de elementos de trabajo o a través del uso compartido de archivos del equipo.

Almacenar orígenes binarios pequeños y actualizados con poca frecuencia en Git

Los archivos de origen binarios que se actualizan con poca frecuencia tienen relativamente pocas versiones confirmadas. No ocupan mucho espacio si su tamaño de archivo es pequeño. Las imágenes de la web, los iconos y otros recursos de arte más pequeños pueden caer en esta categoría. Es mejor almacenar estos archivos en Git con el resto del origen para que el equipo pueda usar un flujo de trabajo coherente.

No confirme recursos binarios grandes y actualizados con frecuencia

Git administra una versión principal de un archivo y, a continuación, almacena solo las diferencias de esa versión, en un proceso conocido como detificación. La detificación y la compresión de archivos permiten a Git almacenar todo el historial de código en el repositorio local. Los archivos binarios grandes normalmente cambian completamente entre versiones y a menudo ya están comprimidos. Estos archivos son difíciles de administrar porque las diferencias entre las versiones son grandes.

Git debe almacenar todo el contenido de cada versión del archivo y tiene dificultades para ahorrar espacio a través de la detificación y compresión. Almacenar las versiones completas de estos archivos hace que el tamaño del repositorio aumente con el tiempo. El aumento del tamaño del repositorio reduce el rendimiento de las ramas, aumenta los tiempos de clonación y amplía los requisitos de almacenamiento.

Estrategias para trabajar con archivos de origen binarios grandes

• No confirme los archivos comprimidos de datos. Es mejor descomprimir los archivos y confirmar los orígenes diffables. Deje que Git controle la compresión de los datos en el repositorio.
• Evite confirmar el código compilado y otras dependencias binarias. Confirme el origen y compile las dependencias, o use una solución de administración de paquetes para la versión y proporcione estos archivos al sistema.
• Almacene la configuración y otros datos estructurados en formatos de texto sin formato diffables, como JSON.

¿Qué es Git LFS?

Cuando tenga archivos de origen con grandes diferencias entre versiones y actualizaciones frecuentes, puede usar Git Large File Storage (LFS) para administrar estos tipos de archivo. Git LFS es una extensión de Git que proporciona datos que describen los archivos grandes de una confirmación en el repositorio. Almacena el contenido del archivo binario en almacenamiento remoto independiente.

Al clonar y cambiar las ramas del repositorio, Git LFS descarga la versión correcta desde ese almacenamiento remoto. Las herramientas de desarrollo local funcionan de forma transparente con los archivos como si se confirmaran directamente en el repositorio.

Ventajas

Una ventaja de Git LFS es que el equipo puede usar el flujo de trabajo de Git de un extremo a otro familiar, independientemente de los archivos que cree el equipo. LFS controla archivos grandes para evitar que afecten negativamente al repositorio general. Además, a partir de la versión 2.0, Git LFS admite el bloqueo de archivos para ayudar a su equipo a trabajar en recursos grandes e indiffables como vídeos, sonidos y mapas de juegos.

Git LFS es totalmente compatible y gratuito en Azure DevOps Services. Para usar LFS con Visual Studio, necesita Visual Studio 2015 Update 2 o posterior. Solo tiene que seguir las instrucciones para instalar el cliente, configurar el seguimiento de LFS para archivos en el repositorio local y, a continuación, insertar los cambios en Azure Repos.

Limitaciones

Git LFS tiene algunas desventajas que debe tener en cuenta antes de adoptarla:

• Cada cliente de Git que use el equipo debe instalar el cliente de Git LFS y comprender su configuración de seguimiento.
• Si el cliente de Git LFS no está instalado y configurado correctamente, no verá los archivos binarios confirmados a través de Git LFS al clonar el repositorio. Git descargará los datos que describen el archivo grande (que es lo que git LFS confirma en el repositorio) y no el archivo binario. La confirmación de archivos binarios grandes sin el cliente de Git LFS instalado insertará el archivo binario en el repositorio.
• Git no puede combinar los cambios de dos versiones diferentes de un archivo binario, incluso si ambas versiones tienen un elemento primario común. Si dos personas trabajan en el mismo archivo al mismo tiempo, deben trabajar conjuntamente para conciliar sus cambios para evitar sobrescribir el trabajo del otro. Git LFS proporciona bloqueo de archivos para ayudar. Los usuarios deben seguir teniendo cuidado para extraer siempre la copia más reciente de un recurso binario antes de comenzar el trabajo.
• Actualmente, Azure Repos no admite el uso de Secure Shell (SSH) en repositorios con archivos de seguimiento de LFS de Git.
• Si un usuario arrastra un archivo binario a través de la interfaz web a un repositorio configurado para Git LFS, el binario se confirma en el repositorio, no en los punteros que se confirmarían a través del cliente de Git LFS.
• Aunque no hay una restricción estricta de tamaño de archivo, el espacio libre disponible del servidor y la carga de trabajo actual podrían restringir el rendimiento y la funcionalidad.
• El límite de tiempo de una carga de archivos es una hora.

Formato de archivo

El archivo escrito en el repositorio para un archivo de seguimiento de LFS de Git tiene algunas líneas con un par clave-valor en cada línea:

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Problemas conocidos

Si usa una versión de LFS anterior a la 2.4.0 con Azure DevOps Server, se requiere un paso de configuración adicional para autenticarse a través de NTLM en lugar de Kerberos. Este paso ya no es necesario a partir de LFS 2.4.0 y se recomienda encarecidamente actualizar.