> ## Documentation Index
> Fetch the complete documentation index at: https://ayakaleaf-pro.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Intégration Git

> Permettez aux utilisateurs de cloner, récupérer (pull) et pousser (push) leurs projets avec Git via le git-bridge.

L'intégration Git est actuellement disponible sur [ayaka-notes/overleaf](https://github.com/ayaka-notes/overleaf).

> [!NOTE]
>
> Cette fonctionnalité a été initialement développée par [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro).

**1. Activer le git-bridge (utilisateurs du Toolkit uniquement)**

Si vous utilisez le Toolkit, activez le `git-bridge` en définissant ce qui suit dans votre `config/overleaf.rc` :

```text title="config/overleaf.rc" theme={null}
GIT_BRIDGE_ENABLED=true
```

Le Toolkit l'ignore sauf si `SERVER_PRO=true` est également défini. Rien d'autre n'est nécessaire : le Toolkit définit lui-même `GIT_BRIDGE_HOST`, `GIT_BRIDGE_PORT` et `V1_HISTORY_URL` pour le conteneur `sharelatex` ; ignorez donc les deux étapes Docker Compose ci-dessous. Exécutez `bin/up` pour recréer les conteneurs.

**2. Ajouter le conteneur git-bridge (utilisateurs de Docker Compose uniquement)**

Si vous utilisez un `docker-compose.yml` personnalisé, ajoutez la configuration de conteneur suivante à votre fichier compose :

```yaml title="docker-compose.yml (git-bridge service)" wrap theme={null}
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"]
```

Utilisez le même tag que l'image `sharelatex`. Le [serveur MCP](https://ayakaleaf-pro.mintlify.site/fr/on-premises/configuration/overleaf-toolkit/integrations/mcp-server.md) (v6.3.1 et ultérieures) fait partie de l'image `sharelatex` et est activé en même temps que l'intégration Git ; il ne nécessite donc aucun conteneur supplémentaire.

**3. Mettre à jour la configuration du conteneur sharelatex**

Vous devrez également lier le conteneur `git-bridge` dans le conteneur `sharelatex` et définir les variables d'environnement suivantes ; faites particulièrement attention à `V1_HISTORY_URL` :

```yaml title="docker-compose.yml (sharelatex service)" theme={null}
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. Authentification**

Pour authentifier un client git, les utilisateurs ont besoin d'un jeton d'accès personnel. Les utilisateurs peuvent gérer leurs jetons d'accès personnels depuis l'interface de l'application (voir la documentation) :

![](https://mintcdn.com/ayakaleaf-pro/UZ_4Jfz7cU6MnXtE/images/on-premises/image-29.png?fit=max\&auto=format\&n=UZ_4Jfz7cU6MnXtE\&q=85\&s=39af379b36baaa023f7cff66dc2dba76)

Jeton d'accès personnel pour l'intégration Git

**5. Surveillance et ressources**

Nous vous recommandons de surveiller les ressources de votre hôte après avoir activé le `git-bridge`. L'augmentation de la charge dépendra :

* du nombre d'utilisateurs accédant à la fonctionnalité
* des types de projets hébergés sur votre instance (les projets plus volumineux sont généralement plus gourmands en ressources)

### Déplacement des projets vers S3

L'intégration Git stocke sur le disque un dépôt git complet pour chaque projet cloné par un utilisateur. Si votre espace disque est limité, vous pouvez activer une tâche de swap qui déplacera les dépôts les moins utilisés vers AWS S3. Si un dépôt déplacé est de nouveau nécessaire, il est rapatrié sur le disque. Les variables d'environnement suivantes contrôlent la tâche de swap :

| Nom | Description |
| - | - |
| `GIT_BRIDGE_SWAPSTORE_TYPE` | Définissez cette valeur sur "s3" pour activer la tâche de swap. |
| `GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY` | Votre clé d'accès AWS |
| `GIT_BRIDGE_SWAPSTORE_AWS_SECRET` | Votre secret AWS |
| `GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME` | Ce bucket contiendra les dépôts git compressés (zip) |
| `GIT_BRIDGE_SWAPSTORE_AWS_REGION` | La région du bucket |
| `GIT_BRIDGE_SWAPJOB_MIN_PROJECTS` | Nombre minimal de projets à conserver sur le disque. **- Par défaut :** 50 |
| `GIT_BRIDGE_SWAPJOB_LOW_GIB` | Seuil bas du swap. La tâche de swap déplacera des projets jusqu'à ce que l'utilisation du disque passe sous cette valeur. **- Par défaut :** 128 Go |
| `GIT_BRIDGE_SWAPJOB_HIGH_GIB` | Seuil haut du swap. La tâche de swap commencera lorsque l'utilisation du disque atteindra cette valeur. **- Par défaut :** 256 Go |
| `GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS` | Intervalle entre deux vérifications de l'utilisation du disque et exécutions de la tâche de swap. **- Par défaut :** 3600000 ms = 1 heure |

### Questions-réponses

> [accordion] Si je partage mon projet avec quelqu'un d'autre, comment fonctionne le modèle de permissions du Git Bridge ?
>
> Les utilisateurs disposant d'un accès en lecture seule peuvent uniquement cloner le projet ; les utilisateurs disposant d'un accès en lecture-écriture peuvent cloner et pousser des modifications. Remarque : les utilisateurs doivent être connectés pour rejoindre ce projet.

> [accordion] Comment cloner un projet, et quels nom d'utilisateur et mot de passe utiliser ?
>
> Dans l'éditeur, ouvrez **Integrations** dans la barre latérale gauche et cliquez sur **Git integration**. La commande de clonage s'affiche, sous la forme :
>
> ```sh theme={null}
> git clone https://<your-overleaf>/git/<project_id>
> ```
>
> Lorsque Git demande des identifiants, saisissez `git` comme nom d'utilisateur et un Personal Access Token comme mot de passe. Générez le jeton dans **Account Settings** ; il est valable un an. Le mot de passe de votre compte ne fonctionne pas.
>
> Les modifications ne sont pas synchronisées automatiquement : utilisez `git pull` pour récupérer les modifications faites dans l'éditeur et `git push` pour envoyer les vôtres. Le chemin `/git` est servi par le conteneur `sharelatex` ; un reverse proxy placé devant ne nécessite donc aucune règle supplémentaire.

> [accordion] `git push` échoue avec `HTTP 413` ou `curl 55 Broken pipe`
>
> Le push dépasse la limite de taille de téléversement, définie par `MAX_UPLOAD_SIZE` (en mégaoctets, `50` par défaut), qui s'applique également aux pushs. Augmentez-la dans `config/variables.env`, par exemple `MAX_UPLOAD_SIZE=200`, puis exécutez `bin/up -d`. Si vous utilisez le [proxy TLS](https://ayakaleaf-pro.mintlify.site/fr/on-premises/configuration/overleaf-toolkit/tls-proxy.md) ou votre propre reverse proxy, augmentez également son `client_max_body_size` (`50M` dans le fichier `config/nginx/nginx.conf` du Toolkit).
>
> Le git-bridge refuse également les fichiers de plus de 50 Mo et les projets de plus de 2 000 fichiers. Ces limites sont définies par `GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE` (en octets) et `GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM` dans `config/variables.env`.

> [accordion] Le journal du git-bridge affiche `Failed to fetch log level`
>
> Cet avertissement est sans danger, et le clonage, le pull et le push continuent de fonctionner. En 6.2.x, le git-bridge interroge le serveur de métadonnées de Google Cloud (`metadata.google.internal`) une fois par minute pour obtenir un niveau de journalisation, ce qui ne fonctionne que sur Google Cloud. Ailleurs, la requête échoue : le git-bridge journalise l'erreur (par exemple `null` ou un statut HTTP) et conserve le niveau défini par `GIT_BRIDGE_LOG_LEVEL`. À partir de la 6.3.0, cette vérification est désactivée, et la mise à niveau met également à jour l'image du git-bridge, dont la version suit celle de l'image principale.

> [accordion] Ai-je besoin du service track-changes ou de `OVERLEAF_IS_SERVER_PRO=true` pour Git et l'historique complet des projets ?
>
> **Réponse :** Non. Ayakaleaf Pro n'a pas de service track-changes. L'historique des projets est conservé par les services `project-history` et `history-v1`, qui s'exécutent toujours dans le conteneur `sharelatex`. Le git-bridge lit l'historique depuis `history-v1` à l'adresse `V1_HISTORY_URL` (`http://sharelatex:3100/api`), que le Toolkit définit. Ne définissez pas `OVERLEAF_IS_SERVER_PRO` : aucune fonctionnalité n'en dépend, elle bascule seulement les migrations de base de données exécutées au démarrage vers celles de Server Pro.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.