Git Large File Storage (LFS) es una aplicación que nos perfimte guardar ficheros binarios de gran tamaño junto un repositorio git.
La forma que tiene git para almacenar las diferencias entre archivos funciona muy bien con ficheros de texto plano o código, pero para ficheros grandes como vídeos, audios, pdfs, ficheros comprimidos, etc. el calcular las diferencias a bajo nivel entre diferentes versiones de dichos ficheros no tiene mucho sentido, además de que como normalmente son ficheros de tamaño considerable supone una gran penalización de rendimiento para el uso normal de git.
Para ello git-lfs lo que hace es que guarda en un fichero de texto dentro del repositorio git un 'puntero' que apunta al fichero binario almacenado en fuera del repositorio git (en la carpeta .git en local). La ubicación de los archivos 'reales' es transparente para el usuario. Supuestamente tanto Github, como Bitbucket, como Gitlab (lo que he probado yo) lo soportan.
En https://github.com/git-lfs/git-lfs/wiki/Installation está la documentación de como lo podemos instalar en linux. Para ello primero necesitamos una versión reciente de git (>= 1.8.2), en Ubuntu podemos usar el ppa:git-core/ppa.
Las instrucciones nos muestran la manera rápida de ejecutar un script desde internet que nos instala el repositorio con los paquetes de git-lfs. Esta opción es una opción peligrosa que no me gusta nada, estas ejecutando con sudo un fichero que no sabes que contiene ni puedes comprobar su autenticidad.
Ya que los paquetes están en PackageCloud he preferido instalarme el repositorio con un playbook de Ansible, básicamente añade el repositorio e instala git-lfs:
---
# file: install_git-lfs.yml
- name: Install Git LFS
hosts: local
become: yes
become_user: root
tasks:
- include: tasks/repo_git_lfs.yml
- name: Install latest git-lfs
apt:
name: git-lfs
state: latestLas tareas necesarias para añadir el repositorio al sistema las he extraido a un fichero externo para mejorar la portabilidad del mismo. Es bastante sencillo, por un lado obtiene la llave GPG comprobando su fingerprint y crea el archivo de origen con el mismo nombre que el script de PackageCloud.
---
# file: tasks/repo_git_lfs.yml
- name: Install Github git-lfs PackageCloud repository prerequisites
apt:
name: apt-transport-https
state: present
- name: Install Github git-lfs PackageCloud repository key
apt_key:
url: "https://packagecloud.io/github/git-lfs/gpgkey"
# Default PackageCloud GPG Key:
id: "C2E73424D59097AB"
state: present
validate_certs: yes
- name: Install Github git-lfs repositry.
apt_repository:
repo: "deb https://packagecloud.io/github/git-lfs/{{ ansible_lsb.id | lower }}/ {{ ansible_lsb.codename }} main"
filename: "github_git-lfs"
mode : 0644
state: present
validate_certs: yes
- name: Install Github git-lfs source repositry.
apt_repository:
repo: "deb-src https://packagecloud.io/github/git-lfs/{{ ansible_lsb.id | lower }}/ {{ ansible_lsb.codename }} main"
filename: "github_git-lfs"
mode : 0644
state: present
validate_certs: yesAl instalarse desde un paquete el proceso ya ejecuta el $ git lfs install que indica en las instrucciones, por lo que no sería necesario.
Para su instalación en Windows yo he partido de la última verión (2.12) de Git Bash https://git-scm.com/download/win, y sencillamente he ejecutado el instalador que aparece sugerido en https://git-lfs.github.com/ cuando se accede desde un ordenador Windows (version 2.0.1).
En principio ya estaría, pero yo me he topado con un problema (de git Bash) de certificados. Estoy trabajando contra una instancia de Gitlab privada con un certificado emitido por una CA privada, aunque el certificado raíz de dicha CA está correctatmene instalado en el sistema git bash utiliza su propio bundle y no lo reconoce. Para solucionarlo se le añade la siguiente línea para configurar git de forma que acepte dicho certificado raíz:
$ git config --global http."https://mi-gitlab.privado/".sslCAInfo C:/Users/Agustin/mi-CA-raiz.crtEn linux no he tenido ningún problema con los certificados.
Inicializamos nuestro repositorio.
$ git initDefinimos el seguimiento de archivos por parte de git-lfs
$ git lfs track '*.zip'
$ git lfs track 'images/image001.jpg'Con la primera línea le decimos a git-lfs que la de gestionar todos los ficheros *.zip, la segunda indica un único archivo, en este caso un .jpg.
Hemos de tener en cuenta que el 'track' solo funciona para los ficheros que no estaban previamente en el repositorio git, si este fuera el caso tendríamos que usar otra herramienta para cambiar la gestión de los ficheros de git a git-lfs.
Aunque los ficheros esten dentro de las indicaciones de seguimiento para git-lfs aún no los hemos añadido al staging, para ello usamos git add como normalmente.
$ git add files/*.zip
$ git add images/image001.jpgPodemos comprobar el estado de los ficheros gestionados con git-lfs usando el comando
git lfs statusComo aún no hemos hecho commit nos mostrara los ficheros anteriores como Git LFS objects to be committed. Realizamos el commit.
$ git commit -m "Add files for git-lfs"Podemos ver que el estado de los ficheros ha cambiado ejecutando de nuevo el comando
git lfs statusAhora nos tocaría hacer push de nuestros cambios a un repositorio remoto, con
git push originnos debería funcionar directamente, pero git-lfs tiene unos pequeños inconvenientes que hacen que su uso no sea del todo transparente.
Git-lfs actualmente solo soporta el proceso de subir ficheros al servidor mediante el protocolo http/s. En el caso de que tengamos configurado nuestro remoto con ssh y utilicemos llaves ssh para identificarnos contra el servidor al hacer git push se nos solicitará de todas formas la contraseña de nuestro usuario en el servidor (Gitlab en mi caso) para que git-lfs pueda subir los ficheros.
Para cada ficheo que se suba al servidor git-lfs pide usuario/contraseña al menos una vez. En windows el sistema gestiona la contraseña durante la sesion de forma que solo hay que introducirla una vez, pero el diálogo no deja copiar la contraseña (lo cual es un engorro si usas contraseñas largas y aleatorias). En linux toca repetir el usuario/contraseña unas cuantas veces. En la wiki del proyecto en Github se nombran programas que cachean las contraseñas para evitar reintroducirla cada vez, pero lo suyo es que incluyera algún tipo de protocolo que gestionara un token de autenticación para el acceso http a traves de la conexión ssh.
Para el caso de $ git pull para traernos el repositorio entero parece ser que los ficheros se descargan aunque tengamos configurado el acceso remoto por ssh.
Aunque su uso aún no es completamente transparente para el ususario git-lfs es una buena alternativa para poder centralizar todos los ficheros que se necesitan en un proyecto. Tendré que ver como evoluciona el servidor Gitlab, y si supone algún problema su uso normal para el espacio de disco del servidor.