Integración con Git

Permite que los usuarios clonen sus proyectos y hagan pull y push con Git a través del git-bridge.

Actualmente, la integración con Git está disponible en ayaka-notes/overleaf.

Esta funcionalidad fue desarrollada inicialmente por ayaka-notes/ayakaleaf-pro.

1. Habilitar git-bridge (solo para usuarios del Toolkit)

   Si usas el Toolkit, habilita git-bridge configurando lo siguiente en tu config/overleaf.rc:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   El Toolkit lo ignora a menos que también se establezca SERVER_PRO=true. No se necesita nada más: el propio Toolkit define GIT_BRIDGE_HOST, GIT_BRIDGE_PORT y V1_HISTORY_URL para el contenedor sharelatex, así que omite los dos pasos de Docker Compose siguientes. Ejecuta bin/up para volver a crear los contenedores.

2. Añadir el contenedor git-bridge (solo para usuarios de Docker-compose)

   Si ejecutas un docker-compose.yml personalizado, añade la siguiente configuración de contenedor a tu archivo compose:

   docker-compose.yml (git-bridge service)

   git-bridge:
       restart: always
       image: ghcr.io/ayaka-notes/overleaf-pro/git-bridge:6.3.2 # tag should match the `sharelatex` container tag
       volumes:
           - ~/git_bridge_data:/data/git-bridge
       container_name: git-bridge
       expose:
           - "8000"
       environment:
           GIT_BRIDGE_API_BASE_URL: "http://sharelatex:3000/api/v0/" 
           GIT_BRIDGE_OAUTH2_SERVER: "http://sharelatex"
           GIT_BRIDGE_POSTBACK_BASE_URL: "http://git-bridge:8000"
           GIT_BRIDGE_ROOT_DIR: "/data/git-bridge"
       user: root
       command: ["/server-pro-start.sh"]
   

   Usa la misma etiqueta que la imagen sharelatex. El servidor MCP (v6.3.1 y posteriores) forma parte de la imagen sharelatex y se habilita junto con la integración con Git, así que no necesita ningún contenedor adicional.

3. Actualizar la configuración del contenedor sharelatex

   También tendrás que enlazar el contenedor git-bridge en el contenedor sharelatex y definir las siguientes variables de entorno; presta atención a V1_HISTORY_URL:

   docker-compose.yml (sharelatex service)

   sharelatex:
       links:
           - git-bridge
       environment:
            GIT_BRIDGE_ENABLED: true
            GIT_BRIDGE_HOST: "git-bridge"
            GIT_BRIDGE_PORT: "8000"
            # We use v1 now, if you used to set V1_HISTORY_URL, please update now
            V1_HISTORY_URL: "http://sharelatex:3100/api"
   
4. Autenticación

   Para autenticar un cliente git, los usuarios necesitan un token de acceso personal (Personal Access Token). Los usuarios pueden gestionar sus tokens de acceso personal desde la interfaz de la aplicación (consulta la documentación):

   

   Token de acceso personal de la integración con Git

5. Supervisión y consideraciones de recursos

   Te recomendamos supervisar los recursos del host después de habilitar git-bridge. El aumento de carga dependerá de:

   • el número de usuarios que acceden a la funcionalidad
   • los tipos de proyectos alojados en tu instancia (los proyectos más grandes suelen consumir más recursos)

​

Mover proyectos a S3

La integración con Git almacena en disco un repositorio git completo por cada proyecto que clona un usuario. Si tienes un espacio en disco limitado, puedes activar un trabajo de intercambio (swap) que moverá a AWS S3 los repositorios menos utilizados. Si se vuelve a necesitar un repositorio movido, se devuelve al disco. Las siguientes variables de entorno controlan el trabajo de intercambio:

Nombre	Descripción
GIT_BRIDGE_SWAPSTORE_TYPE	Establécela en “s3” para activar el trabajo de intercambio.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	Tu clave de acceso de AWS
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	Tu secreto de AWS
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Este bucket contendrá los repositorios git comprimidos
GIT_BRIDGE_SWAPSTORE_AWS_REGION	La región del bucket
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Cuántos proyectos mantener en disco, como mínimo. - Por defecto: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Umbral inferior de intercambio. El trabajo de intercambio moverá proyectos hasta que el uso del disco esté por debajo de este valor. - Por defecto: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Umbral superior de intercambio. El trabajo de intercambio empezará a mover proyectos cuando el uso del disco alcance este valor. - Por defecto: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	El tiempo entre cada comprobación del uso del disco y la ejecución del trabajo de intercambio. - Por defecto: 3600000 ms = 1 hora

​

Preguntas y respuestas

Si comparto mi proyecto con otra persona, ¿cómo funciona el modelo de permisos de Git Bridge?

Los usuarios con acceso de solo lectura solo pueden clonar el proyecto; los usuarios con acceso de lectura y escritura pueden clonar y hacer push. Nota: los usuarios deben haber iniciado sesión para unirse al proyecto.

¿Cómo clono un proyecto y qué nombre de usuario y contraseña uso?

En el editor, abre Integrations en la barra lateral izquierda y haz clic en Git integration. Se muestra el comando de clonación, con el formato:

git clone https://<your-overleaf>/git/<project_id>

Cuando Git pida las credenciales, introduce git como nombre de usuario y un token de acceso personal (Personal Access Token) como contraseña. Genera el token en Account Settings; es válido durante un año. La contraseña de tu cuenta no funciona.

Los cambios no se sincronizan automáticamente: usa git pull para obtener los cambios hechos en el editor y git push para enviar los tuyos. La ruta /git la sirve el contenedor sharelatex, así que un proxy inverso delante de él no necesita ninguna regla adicional.

git push falla con HTTP 413 o curl 55 Broken pipe

El push supera el límite de tamaño de subida, que se define con MAX_UPLOAD_SIZE (en megabytes, 50 por defecto) y también se aplica a los push. Auméntalo en config/variables.env, por ejemplo MAX_UPLOAD_SIZE=200, y después ejecuta bin/up -d. Si usas el proxy TLS o tu propio proxy inverso, aumenta también su client_max_body_size (50M en el config/nginx/nginx.conf del Toolkit).

El git-bridge también rechaza archivos de más de 50 MB y proyectos con más de 2000 archivos. Estos límites se definen con GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (en bytes) y GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM en config/variables.env.

El log de git-bridge muestra Failed to fetch log level

La advertencia es inofensiva, y clone, pull y push siguen funcionando. En la 6.2.x, git-bridge pide un nivel de log al servidor de metadatos de Google Cloud (metadata.google.internal) una vez por minuto, lo que solo funciona en Google Cloud. En cualquier otro entorno la solicitud falla, git-bridge registra el error (como null o un código de estado HTTP) y mantiene el nivel de GIT_BRIDGE_LOG_LEVEL. A partir de la 6.3.0 la comprobación está desactivada, y la actualización también actualiza la imagen de git-bridge, cuya versión sigue a la de la imagen principal.

¿Necesito el servicio track-changes o OVERLEAF_IS_SERVER_PRO=true para Git y el historial completo del proyecto?

Respuesta: No. Ayakaleaf Pro no tiene servicio track-changes. El historial del proyecto lo conservan los servicios project-history y history-v1, que siempre se ejecutan dentro del contenedor sharelatex. El git-bridge lee el historial de history-v1 en V1_HISTORY_URL (http://sharelatex:3100/api), que define el Toolkit. No establezcas OVERLEAF_IS_SERVER_PRO: ninguna función depende de ella; solo cambia las migraciones de base de datos que se ejecutan al arrancar al conjunto de Server Pro.