Compartir a través de

Administración y almacenamiento de archivos grandes en Git

  • Artículo

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

Git ayuda a reducir la superficie del código fuente porque las diferencias entre las versiones se detectan de forma sencilla y el código se comprime fácilmente. Los archivos grandes que no se comprimen bien y cambian completamente entre versiones (como los 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 que no se pueden comparar en el repositorio (como archivos binarios), mantendrá una copia completa de ese archivo en el repositorio cada vez que confirme un cambio en él. Si existen muchas versiones de estos archivos en el repositorio, aumentarán considerablemente el tiempo de extracción del repositorio, bifurcación, captura y clonación del código.

¿Qué tipo de archivos debe almacenar en Git?

Confirmar el código fuente, no las 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, por ejemplo archivos DLL, archivos de biblioteca y otras dependencias que no su equipo no crea, pero de los que dependa su código. Entregue estos archivos a los sistemas mediante la administración de paquetes.

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

No confirmar salidas

No confirme archivos binarios, registros, resultados de seguimiento o datos de diagnóstico de las compilaciones y pruebas. Se trata de salidas del código, no del propio código fuente. Comparta registros e información de seguimiento con el equipo mediante herramientas de seguimiento de elementos de trabajo o mediante el uso compartido de archivos de equipo.

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

Los archivos de código fuente binarios que se actualizan con poca frecuencia tendrán relativamente pocas versiones confirmadas. No ocuparán mucho espacio siempre que su tamaño de archivo sea reducido. Las imágenes para la web, los iconos y otros recursos de arte más pequeños pueden incluirse en esta categoría. Es mejor almacenar estos archivos en Git con el resto del código fuente para que el equipo pueda usar un flujo de trabajo coherente.

Importante

Incluso los archivos binarios pequeños pueden causar problemas si se actualizan con frecuencia. Por ejemplo, para 100 cambios en un archivo binario de 100 KB se usa tanto almacenamiento como para 10 cambios en un archivo binario de 1 MB. Debido a la frecuencia de las actualizaciones, el binario más pequeño ralentizará el rendimiento de la bifurcación con más frecuencia que el binario grande.

No confirmar recursos binarios grandes y actualizados con frecuencia

Git administrará una versión principal de un archivo y, después, almacenará sólo las diferencias de esa versión en un proceso conocido como creación de diferencias. La creación de diferencias y la compresión de archivos permiten a Git almacenar todo el historial de código en el repositorio local. Los archivos binarios grandes suelen cambiar totalmente entre versiones y, a menudo, ya están comprimidos. Estos archivos son difíciles de administrar en Git, ya que la diferencia entre las versiones es muy grande.

Git debe almacenar todo el contenido de cada versión del archivo y tiene dificultades para ahorrar espacio mediante la creación de diferencias y la compresión. El almacenamiento de 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 la bifurcación, aumenta los tiempos de clonación y amplía los requisitos de almacenamiento.

Estrategias para trabajar con archivos de código fuente binarios grandes

  • No confirme archivos de datos comprimidos. Es mejor descomprimirlos y confirmar los orígenes que no se pueden comparar. Esto permite a Git controlar la compresión de los datos en el repositorio.
  • Evite confirmar código compilado y otras dependencias binarias. Confirme el origen y compile las dependencias, o bien use una solución de administración de paquetes para crear versiones de estos archivos y proporcionarlos al sistema.
  • Almacene la configuración y otros datos estructurados en formatos de texto sin formato que no se puedan comparar, como JSON.

¿Qué es Git LFS?

Si tiene archivos de código fuente con grandes diferencias entre las versiones y actualizaciones frecuentes, puede usar el almacenamiento de archivos grandes (LFS) de Git para administrar estos tipos de archivos. Git LFS es una extensión para Git que confirma los datos que describen los archivos grandes en una confirmación en el repositorio. Almacena el contenido de los archivos binarios en un almacenamiento remoto independiente.

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

Ventajas

La ventaja de Git LFS es que el equipo puede usar el flujo de trabajo familiar de un extremo a otro de Git, independientemente de los archivos que cree el equipo. LFS gestiona 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 al equipo a trabajar en recursos grandes y que no se pueden comparar, como vídeos, sonidos y mapas de juegos.

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

Limitaciones

Git LFS tiene algunas desventajas que debe tener en cuenta antes de la adopción:

  • 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 LFS de Git no está instalado ni configurado correctamente, no verá los archivos binarios confirmados a través del LFS de Git 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 propio archivo binario. Si se confirman archivos binarios grandes sin tener instalado el cliente de Git LFS, se enviarán los cambios del archivo binario al repositorio.
  • Git no puede combinar los cambios de dos versiones diferentes de un archivo binario aunque ambas versiones tengan un elemento primario común. Si dos personas están trabajando en el mismo archivo al mismo tiempo, deben trabajar conjuntamente para conciliar sus cambios a fin de evitar sobrescribir el trabajo del otro. Git LFS proporciona el bloqueo de archivos como ayuda. Aun así, los usuarios deben tener cuidado de incorporar siempre los cambios de la copia más reciente de un recurso binario antes de comenzar a trabajar.
  • Azure Repos actualmente no admite el uso de Secure Shell (SSH) en repositorios con archivos con seguimiento de Git LFS.
  • Si un usuario arrastra y coloca un archivo binario a través de la interfaz web en un repositorio que está configurado para Git LFS, el archivo binario se confirmará en el repositorio y no en los punteros que se confirmarían a través del cliente de Git LFS.
  • Aunque no existe una restricción estricta en el tamaño de los archivos, el espacio libre disponible en el servidor y la carga de trabajo actual podrían limitar el rendimiento y la funcionalidad.
  • El límite de tiempo de carga por archivo es de una hora.

Formato de archivo

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

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

Nota:

La dirección URL de GitHub incluida para el valor de versión sólo define el tipo de archivo de puntero de LFS. No es un vínculo al archivo binario.

Problemas conocidos

Si usa una versión de LFS inferior a la versión 2.4.0 con Azure DevOps Server o TFS, debe realizar un paso adicional de configuración necesario para autenticarse mediante NTLM en lugar de Kerberos. Este paso ya no es necesario a partir de la versión 2.4.0 de LFS y se recomienda encarecidamente llevar a cabo la actualización oportuna.