Close

¿Qué es Git LFS?


Git es un sistema de control de versiones distribuido, lo que significa que todo el historial del repositorio se transfiere al cliente durante el proceso de clonación. Para proyectos que contienen archivos grandes, especialmente archivos grandes que se modifican con regularidad, este clon inicial puede tardar mucho tiempo, ya que el cliente debe descargar todas las versiones de cada archivo. Git LFS (Large File Storage) es una extensión de Git desarrollada por Atlassian, GitHub y algunos otros colaboradores de código abierto, que reduce el impacto de los archivos grandes en tu repositorio al descargar las versiones relevantes de ellos de forma lenta. Específicamente, los archivos grandes se descargan durante el proceso de extracción en lugar de durante la clonación o la recuperación.

Para ello, Git LFS reemplaza los archivos grandes de tu repositorio por pequeños archivos de puntero. Durante el uso normal, no verás estos archivos de puntero, ya que Git LFS se ocupa de ellos automáticamente:

1. Al añadir un archivo a tu repositorio, Git LFS reemplaza su contenido por un puntero y almacena el contenido del archivo en una memoria caché local de Git LFS.

Diagrama de git add
bases de datos
Material relacionado

Cómo mover un repositorio de Git completo

Logotipo de Bitbucket
VER LA SOLUCIÓN

Aprende a usar Git con Bitbucket Cloud

2. Cuando envías nuevas confirmaciones al servidor, todos los archivos de Git LFS a los que hagan referencia las confirmaciones recién enviadas se transfieren desde la caché local de Git LFS al almacenamiento remoto de Git LFS vinculado con el repositorio de Git.

Diagrama git push

Cuando extraes una confirmación que contiene punteros de Git LFS, se sustituyen por archivos de la caché local de Git LFS o se descargan del almacenamiento remoto de Git LFS.

Diagrama git push

Git LFS funciona sin problemas: en tu copia de trabajo solo verás el contenido real del archivo. De esta forma, puedes usar Git LFS sin cambiar tu flujo de trabajo de Git existente; tan solo tienes que hacer git checkout, editar, git add y git commit como harías normalmente. Las operaciones de git clone y git pull serán mucho más rápidas, ya que solo descargas las versiones de archivos grandes a los que hacen referencia las confirmaciones que realmente extraes, en lugar de todas las versiones del archivo que hayan existido.

Para usar Git LFS, necesitarás un host compatible con Git LFS, como Bitbucket Cloud o Bitbucket Data Center. Los usuarios del repositorio deberán tener instalado el cliente de línea de comandos de Git LFS o un cliente de GUI compatible con Git LFS, como Sourcetree. Como curiosidad, Steve Streeting, el desarrollador de Atlassian que inventó Sourcetree, también es uno de los principales colaboradores del proyecto Git LFS, por lo que Sourcetree y Git LFS funcionan bastante bien juntos.

Instalar Git LFS


1. Hay tres formas de instalar Git LFS, todas muy sencillas:

a. Instálalo con tu gestor de paquetes favorito. Hay paquetes de git-lfs para Homebrew, MacPorts, dnf y packagecloud.

b. Descarga e instala Git LFS desde el sitio web del proyecto.

c. Instala Sourcetree, un cliente GUI de Git gratuito que viene incluido con Git LFS.

2. Cuando git-lfs esté en tu ruta, ejecuta git lfs install para inicializar Git LFS (puedes saltar este paso si has instalado Sourcetree):

$ git lfs install Git LFS initialized. 

Solo tienes que ejecutar git lfs install una vez. Una vez inicializado para tu sistema, Git LFS se iniciará automáticamente cada vez que clones un repositorio que tenga contenido de Git LFS.

Crear un repositorio nuevo de Git LFS


Para crear un nuevo repositorio compatible con Git LFS, tendrás que ejecutar git lfs install después de crear el repositorio:

# initialize Git
$ mkdir Atlasteroids
$ cd Atlasteroids
$ git init
Initialized empty Git repository in /Users/tpettersen/Atlasteroids/.git/
  
# initialize Git LFS
$ git lfs install
Updated pre-push hook.
Git LFS initialized.

Esto instala un hook de Git especial pre-push en tu repositorio que transferirá los archivos de Git LFS al servidor cuando hagas git push.

Git LFS se habilita automáticamente para todos los repositorios de Bitbucket Cloud. Para Bitbucket Data Center, tendrás que habilitar Git LFS en la configuración del repositorio:

Git LFS de Bitbucket

En cuanto Git LFS se inicializa para tu repositorio, puedes especificar qué archivos quieres rastrear con git lfs track.

Clonar un repositorio de Git LFS que ya existe


Una vez instalado Git LFS, puedes clonar un repositorio de Git LFS de forma normal con git clone. Al finalizar la clonación, Git extraerá la rama predeterminada (normalmente main) y se descargarán automáticamente todos los archivos de Git LFS necesarios para llevar a cabo el proceso de extracción. Por ejemplo:

$ git clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 31.00 KiB/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Downloading Assets/Sprites/projectiles-spritesheet.png (21.14 KB)
Downloading Assets/Sprites/productlogos_cmyk-spritesheet.png (301.96 KB)
Downloading Assets/Sprites/shuttle2.png (1.62 KB)
Downloading Assets/Sprites/space1.png (1.11 MB)
Checking out files: 100% (81/81), done.

Git LFS está rastreando cuatro PNG en este repositorio. Al ejecutar git clone, los archivos de Git LFS se descargan uno por uno a medida que los archivos de puntero se extraen de tu repositorio.

Acelerar clones


Si vas a clonar un repositorio con una gran cantidad de archivos LFS, el comando git lfs clone explícito ofrece un rendimiento mucho mejor:

$ git lfs clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB

En lugar de descargar los archivos de Git LFS de uno en uno, el comando git lfs clone espera hasta que finaliza la extracción y, a continuación, descarga los archivos de Git LFS necesarios en lote. Esto aprovecha las descargas en paralelo y reduce enormemente la cantidad de solicitudes y procesos HTTP generados (lo cual es especialmente importante para mejorar el rendimiento en Windows).

Incorporar y extraer


Al igual que con la clonación, puedes incorporar cambios desde un repositorio de Git LFS usando un git pull normal. Todos los archivos de Git LFS necesarios se descargarán dentro del proceso de extracción automático una vez que se lleve a cabo la incorporación:

$ git pull
Updating 4784e9d..7039f0a
Downloading Assets/Sprites/powerup.png (21.14 KB)
Fast-forward
 Assets/Sprites/powerup.png      |    3 +
 Assets/Sprites/powerup.png.meta | 4133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 4136 insertions(+)
 create mode 100644 Assets/Sprites/projectiles-spritesheet.png
 create mode 100644 Assets/Sprites/projectiles-spritesheet.png.meta

No se necesitan comandos explícitos para recuperar el contenido de Git LFS. Sin embargo, si la extracción falla por un motivo inesperado, puedes descargar los contenidos de Git LFS que falten para la confirmación actual con git lfs pull:

$ git lfs pull
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MB

Acelerar la incorporación de cambios


Al igual que git lfs clone, git lfs pull descarga los archivos de Git LFS en lote. Si sabes que una gran cantidad de archivos han cambiado desde la última vez que incorporaste cambios, es posible que quieras deshabilitar la descarga automática de Git LFS durante la extracción y, a continuación, descargar por lotes el contenido de Git LFS con un comando git lfs pull explícito. Para esto puedes anular tu configuración de Git con la opción -c cuando invocas git pull:

$ git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull

Como esto supone mucha escritura, es posible que quieras crear un alias de Git sencillo para que realice una incorporación por lotes de Git y Git LFS:

$ git config --global alias.plfs "\!git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull"
$ git plfs

Esto mejorará en gran medida el rendimiento cuando tengas que descargar una gran cantidad de archivos de Git LFS (como he dicho, esto es muy práctico en Windows).

Rastrear archivos con Git LFS


Cuando añadas un nuevo tipo de archivo grande a tu repositorio, tendrás que indicarle a Git LFS que lo rastree especificando un patrón con el comando git lfs track:

$ git lfs track "*.ogg"
Tracking *.ogg

Ten en cuenta que las comillas de "*.ogg" son importantes. Si las omites, el shell expandirá el comodín y se crearán entradas individuales para cada archivo .ogg de tu directorio actual:

# probably not what you want
$ git lfs track *.ogg
Tracking explode.ogg
Tracking music.ogg
Tracking phaser.ogg

Los patrones admitidos por Git LFS son los mismos que los que admite .gitignore, por ejemplo:

# track all .ogg files in any directory
$ git lfs track "*.ogg"
  
# track files named music.ogg in any directory
$ git lfs track "music.ogg"
  
# track all files in the Assets directory and all subdirectories
$ git lfs track "Assets/"
  
# track all files in the Assets directory but *not* subdirectories
$ git lfs track "Assets/*"
  
# track all ogg files in Assets/Audio
$ git lfs track "Assets/Audio/*.ogg"
  
# track all ogg files in any directory named Music
$ git lfs track "**/Music/*.ogg"
  
# track png files containing "xxhdpi" in their name, in any directory
$ git lfs track "*xxhdpi*.png

Estos patrones se refieren al directorio en el que ejecutó el comando git lfs track. Para simplificar las cosas, es mejor ejecutar git lfs track desde la raíz del repositorio. Recuerda que Git LFS no admite patrones negativos, a diferencia de .gitignore que sí lo hace.

Después de ejecutar git lfs track, verás un nuevo archivo llamado .gitattributes en el directorio desde el que ejecutaste el comando. .gitattributes es un mecanismo de Git para vincular comportamientos especiales a ciertos patrones de archivo. Git LFS crea o actualiza automáticamente archivos .gitattributes para vincular patrones de archivo rastreados al filtro de Git LFS. Sin embargo, tendrás que confirmar los cambios en el archivo .gitattributes en tu repositorio tú mismo:

$ git lfs track "*.ogg"
Tracking *.ogg
  
$ git add .gitattributes
  
$ git diff --cached
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..b6dd0bb
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.ogg filter=lfs diff=lfs merge=lfs -text
  
$ git commit -m "Track ogg files with Git LFS"

Para facilitar el mantenimiento, lo más sencillo es mantener todos los patrones de Git LFS en un solo archivo .gitattributes ejecutando siempre git lfs track desde la raíz del repositorio. Sin embargo, puedes mostrar una lista de todos los patrones de los que Git LFS (y los archivos .gitattributes en los que se definen) invocando git lfs track sin argumentos:

$ git lfs track
Listing tracked paths
    *.stl (.gitattributes)
    *.png (Assets/Sprites/.gitattributes)
    *.ogg (Assets/Audio/.gitattributes)

Para dejar de rastrear un patrón en particular con Git LFS, puedes eliminar la línea apropiada de tu archivo .gitattributes o ejecutar el comando git lfs untrack:

$ git lfs untrack "*.ogg"
Untracking *.ogg
$ git diff
diff --git a/.gitattributes b/.gitattributes
index b6dd0bb..e69de29 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1 +0,0 @@
-*.ogg filter=lfs diff=lfs merge=lfs -text

Después de ejecutar git lfs untrack, tendrás que volver a confirmar los cambios en .gitattributes tú mismo.

Confirmar y enviar


Puedes confirmar y enviar de forma normal a un repositorio que tenga contenido de Git LFS. Si has confirmado cambios en archivos rastreados por Git LFS, verás algunos resultados adicionales de git push cuando el contenido de Git LFS se transfiera al servidor:

$ git push
Git LFS: (3 of 3 files) 4.68 MB / 4.68 MB                                                                                               
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.16 KiB | 0 bytes/s, done.
Total 8 (delta 1), reused 0 (delta 0)
To git@bitbucket.org:tpettersen/atlasteroids.git
   7039f0a..b3684d3  main -> main

Si la transferencia de los archivos LFS falla por algún motivo, el envío se anulará y podrás volver a intentarlo de forma segura. Al igual que Git, el almacenamiento de Git LFS es direccionable por contenido: el contenido se almacena en una clave que es un hash SHA-256 del contenido en sí. Esto significa que siempre es seguro volver a intentar transferir archivos de Git LFS al servidor; no puedes sobrescribir accidentalmente el contenido de un archivo de Git LFS con una versión incorrecta.

Mover un repositorio de Git LFS entre hosts


Para migrar un repositorio de Git LFS de un proveedor de alojamiento a otro, puedes usar una combinación de git lfs fetch y git lfs push especificando la opción --all.

Por ejemplo, para mover todos los repositorios Git y Git LFS de un remoto llamado github a un repositorio remoto llamado bitbucket 😉:

# create a bare clone of the GitHub repository
$ git clone --bare git@github.com:kannonboy/atlasteroids.git
$ cd atlasteroids
  
# set up named remotes for Bitbucket and GitHub
$ git remote add bitbucket git@bitbucket.org:tpettersen/atlasteroids.git
$ git remote add github git@github.com:kannonboy/atlasteroids.git
  
# fetch all Git LFS content from GitHub
$ git lfs fetch --all github
 
# push all Git and Git LFS content to Bitbucket
$ git push --mirror bitbucket
$ git lfs push --all bitbucket

Recuperar historial extra de Git LFS


Por lo general, Git LFS solo descarga los archivos necesarios para las confirmaciones que extraigas de forma local. Sin embargo, puedes forzar a Git LFS a descargar contenido adicional para otras ramas modificadas recientemente con git lfs fetch --recent:

$ git lfs fetch --recent
Fetching main
Git LFS: (0 of 0 files, 14 skipped) 0 B / 0 B, 2.83 MB skipped                                                                           Fetching recent branches within 7 days
Fetching origin/power-ups
Git LFS: (8 of 8 files, 4 skipped) 408.42 KB / 408.42 KB, 2.81 MB skipped
Fetching origin/more-music
Git LFS: (1 of 1 files, 14 skipped) 1.68 MB / 1.68 MB, 2.83 MB skipped

Esto es práctico para descargar por lotes nuevo contenido de Git LFS mientras estás fuera de la oficina o si vas a revisar el trabajo de tus compañeros de equipo y luego no tendrás una buena conexión a Internet para descargar el contenido. Por ejemplo, podrías ejecutar git lfs fetch --recent antes de subir a un avión.

Git LFS considera como reciente cualquier rama o etiqueta que tengan una confirmación de más de siete días. Puedes configurar el número de días que se consideran recientes con la propiedad lfs.fetchrecentrefsdays:

# download Git LFS content for branches or tags updated in the last 10 days
$ git config lfs.fetchrecentrefsdays 10

De forma predeterminada, git lfs fetch --recent solo descargará el contenido de Git LFS para la confirmación que está en la punta de una rama o etiqueta reciente.

git lfs - git lfs fetch --recent

Sin embargo, puedes configurar Git LFS para que descargue contenido para confirmaciones anteriores en ramas y etiquetas recientes con la propiedad lfs.fetchrecentcommitsdays:

# download the latest 3 days of Git LFS content for each recent branch or tag
$ git config lfs.fetchrecentcommitsdays 3

Ten cuidado con este ajuste: si tienes ramas que se mueven rápidamente, puede hacer que se descargue una gran cantidad de datos. Sin embargo, puede venirte bien si tienes que revisar cambios intersticiales en una rama, seleccionar confirmaciones entre ramas distintas con cherry-pick o reescribir el historial.

git lfs - git lfs fetch --recent commits

Como se explica en Mover un repositorio de Git LFS entre hosts, también puedes recuperar todo el contenido de Git LFS para tu repositorio con git lfs fetch --all:

$ git lfs fetch --all
Scanning for all objects ever referenced...
✔ 23 objects found                                                                                                                      
Fetching objects...
Git LFS: (9 of 9 files, 14 skipped) 2.06 MB / 2.08 MB, 2.83 MB skipped

Eliminar archivos locales de Git LFS


Puedes eliminar archivos de tu caché local de Git LFS con el comando git lfs prune:

$ git lfs prune
✔ 4 local objects, 33 retained                                                                                                         
Pruning 4 files, (2.1 MB)
✔ Deleted 4 files

Esto eliminará todos los archivos de Git LFS locales que se consideren antiguos. Un archivo antiguo es cualquier archivo al que no hagan referencia:

  • la confirmación que se está extrayendo en ese momento,
  • una confirmación que aún no se ha enviado (al origen o según la configuración de lfs.pruneremotetocheck) y
  • una confirmación reciente

De forma predeterminada, una confirmación reciente es cualquier confirmación que se haya creado en los últimos diez días. Para calcularlo, se suma lo siguiente:

  • el valor de la propiedad lfs.fetchrecentrefsdays que se describe en Recuperar historial extra de Git LFS (cuyo valor predeterminado es siete) y
  • el valor de la propiedad lfs.pruneoffsetdays (cuyo valor predeterminado es tres).
git lfs prune

Puedes configurar el desplazamiento de prune y conservar el contenido de Git LFS durante más tiempo:

# don't prune commits younger than four weeks (7 + 21)
$ git config lfs.pruneoffsetdays 21

A diferencia de la recolección de elementos no utilizados integrada de Git, el contenido de Git LFS no se elimina automáticamente, por lo que es conveniente ejecutar git lfs prune de forma regular para reducir el tamaño del repositorio local.

Puedes probar qué efecto tendrá una operación de prune con git lfs prune --dry-run:

$ git lfs prune --dry-run
✔ 4 local objects, 33 retained                                                                                                         
4 files would be pruned (2.1 MB)

También puedes ver qué objetos de Git LFS se eliminarán con git lfs prune --verbose --dry-run:

$ git lfs prune --dry-run --verbose
✔ 4 local objects, 33 retained                                                                                                         
4 files would be pruned (2.1 MB)
 * 4a3a36141cdcbe2a17f7bcf1a161d3394cf435ac386d1bff70bd4dad6cd96c48 (2.0 MB)
 * 67ad640e562b99219111ed8941cb56a275ef8d43e67a3dac0027b4acd5de4a3e (6.3 KB)
 * 6f506528dbf04a97e84d90cc45840f4a8100389f570b67ac206ba802c5cb798f (1.7 MB)
 * a1d7f7cdd6dba7307b2bac2bcfa0973244688361a48d2cebe3f3bc30babcf1ab (615.7 KB)

Las cadenas hexadecimales largas generadas por el modo --verbose son hashes SHA-256 (también conocidos como ID de objeto u OID) de los objetos Git LFS que se van a eliminar. Puedes usar las técnicas detalladas en Buscar rutas o confirmaciones que hagan referencia a un objeto de Git LFS para obtener más información sobre los objetos que se eliminarán.

Como comprobación de seguridad adicional, puedes usar la opción --verify-remote para comprobar si el almacenamiento remoto de Git LFS tiene una copia de tus objetos de Git LFS antes de que se eliminen:

$ git lfs prune --verify-remote
✔ 16 local objects, 2 retained, 12 verified with remote                                                                                             
Pruning 14 files, (1.7 MB)
✔ Deleted 14 files

Esto hace mucho más lento el proceso de eliminación, pero te da la tranquilidad de saber que los objetos eliminados se podrán recuperar del servidor. Puedes habilitar la opción --verify-remote permanentemente en el sistema configurando la propiedad lfs.pruneverifyremotealways de forma global:

$ git config --global lfs.pruneverifyremotealways true 

También puedes omitir la opción --global del comando anterior para habilitar la verificación remota solamente para el repositorio de contexto.

Eliminar archivos remotos de Git LFS del servidor


El cliente de línea de comandos de Git LFS no permite eliminar archivos del servidor con prune, y la forma de eliminarlos dependerá de tu proveedor de alojamiento.

En Bitbucket Cloud, puedes ver y eliminar archivos de Git LFS en Configuración del repositorio> Git LFS:

Bitbucket Cloud: eliminar lfs del servidor

Recuerda que todos los archivos de Git LFS están indexados por su OID SHA-256; las rutas que hacen referencia a cada archivo no se pueden ver a través de la interfaz de usuario. Esto es así porque puede haber muchas rutas diferentes en muchas confirmaciones diferentes que pueden referirse a un objeto determinado, por lo que buscarlas sería un proceso muy lento.

Para determinar qué contiene realmente un archivo de Git LFS determinado, tienes tres opciones:

  • Fíjate en la imagen de vista previa del archivo y en el tipo de archivo en la columna izquierda de la interfaz de usuario de Bitbucket Git LFS.
  • Descarga el archivo con el enlace en la columna derecha de la interfaz de usuario de Bitbucket Git LFS. O busca confirmaciones que hagan referencia al OID SHA-256 del objeto Git LFS, como se explica en la siguiente sección.

Buscar rutas o confirmaciones que hagan referencia a un objeto de Git LFS


Si tienes un OID SHA-256 de Git LFS, puedes determinar qué confirmaciones le hacen referencia con git log --all -p -S< OID>:

$ git log --all -p -S 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
commit 22a98faa153d08804a63a74a729d8846e6525cb0
Author: Tim Pettersen <tpettersen@atlassian.com>
Date:   Wed Jul 27 11:03:27 2016 +1000
 
    Projectiles and exploding asteroids
 
diff --git a/Assets/Sprites/projectiles-spritesheet.png
new file mode 100755
index 0000000..49d7baf
--- /dev/null
+++ b/Assets/Sprites/projectiles-spritesheet.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
+size 21647

Este código de git log genera un parche (-p) a partir de confirmaciones de cualquier rama (--all) que agregan o eliminan una línea (-S) que contiene la cadena especificada (un OID SHA-256 de Git LFS).

El parche te muestra la confirmación y la ruta al objeto de LFS, así como quién lo ha añadido y cuándo se confirmó. Puedes extraer la confirmación y Git LFS descargará el archivo si es necesario y lo colocará en tu copia de trabajo.

Si sospechas que un objeto de Git LFS en particular está en tu HEAD o en una rama en particular, puedes usar git grep para buscar la ruta del archivo de referencia:

# find a particular object by OID in HEAD
$ git grep 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc HEAD
HEAD:Assets/Sprites/projectiles-spritesheet.png:oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
  
# find a particular object by OID on the "power-ups" branch
$ git grep e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4 power-ups
power-ups:Assets/Sprites/shield2.png:oid sha256:e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4

Puedes sustituir HEAD o power-ups con cualquier referencia, confirmación o árbol que contenga el objeto de Git LFS.

Incluir/excluir archivos de Git LFS


En algunos casos, puede que quieras descargar solo un subconjunto del contenido disponible de Git LFS para una confirmación en particular. Por ejemplo, al configurar una compilación de CI para ejecutar pruebas unitarias, es posible que solo necesites tu código fuente y excluir archivos pesados que no son necesarios para compilar el código.

Puedes excluir un patrón o subdirectorio con git lfs fetch -X (o --exclude):

$ git lfs fetch -X "Assets/**" 

También puede que solo quieras incluir un patrón o subdirectorio en particular. Por ejemplo, un ingeniero de sonido podría recuperar solamente archivos ogg y wav con git lfs fetch -I (o --include):

$ git lfs fetch -I "*.ogg,*.wav" 

Si combinas inclusiones y exclusiones, solo se recuperarán archivos que coincidan con un patrón de inclusión y no coincidan con un patrón de exclusión. Por ejemplo, puedes recuperar todo lo que hay en tu directorio Assets, salvo los gif con:

$ git lfs fetch -I "Assets/**" -X "*.gif" 

Las exclusiones e inclusiones son compatibles con los mismos patrones que git lfs track y .gitignore. Puedes hacer que estos patrones sean permanentes para un repositorio en particular estableciendo las propiedades de configuración lfs.fetchinclude y lfs.fetchexclude:

$ git config lfs.fetchinclude "Assets/**"
$ git config lfs.fetchexclude "*.gif"

Estas configuraciones también se pueden aplicar a todos los repositorios de tu sistema agregando la opción --global.

Bloquear archivos de Git LFS


Lamentablemente, no hay una forma sencilla de resolver los conflictos de fusión binaria. Con el bloqueo de archivos de Git LFS, puedes bloquear archivos por extensión o por nombre de archivo y evitar que los archivos binarios se sobrescriban durante una fusión.

Para utilizar la función de bloqueo de archivos de LFS, primero debes decirle a Git qué tipo de archivos se pueden bloquear. En el ejemplo siguiente, la marca `--lockable` se añade al comando `git lfs track` que almacena archivos PSD en LFS y los marca como bloqueables.

$ git lfs track "*.psd" --lockable

A continuación, añade lo siguiente a tu archivo .gitattributes:

*.psd filter=lfs diff=lfs merge=lfs -text lockable

Cuando te prepares para hacer cambios en un archivo LFS, utilizarás el comando lock para registrar el archivo como bloqueado en el servidor de Git.

$ git lfs lock images/foo.psd
Locked images/foo.psd

Cuando ya no necesites el bloqueo de archivos, puedes eliminarlo con el comando de desbloqueo de Git LFS.

$ git lfs unlock images/foo.psd

Los bloqueos de archivos de Git LFS se pueden anular (de manera similar a git push) con una marca --force. No uses la marca --force a menos de que tengas absoluta certeza de lo que estás haciendo.

$ git lfs unlock images/foo.psd --force

Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Gente que colabora utilizando un muro lleno de herramientas

Blog de Bitbucket

Ilustración de Devops

Ruta de aprendizaje de DevOps

Demostraciones de funciones con expertos de Atlassian del Centro de demostraciones

Cómo funciona Bitbucket Cloud con Atlassian Open DevOps

Suscríbete para recibir el boletín de DevOps

Thank you for signing up