> ## 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.

# Git-Integration

> Lassen Sie Benutzer ihre Projekte über die git-bridge mit Git klonen, pullen und pushen.

Die Git-Integration ist derzeit unter [ayaka-notes/overleaf](https://github.com/ayaka-notes/overleaf) verfügbar.

> [!NOTE]
>
> Diese Funktion wurde ursprünglich von [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro) entwickelt.

**1. git-bridge aktivieren (nur für Toolkit-Nutzer)**

Wenn Sie das Toolkit verwenden, aktivieren Sie die `git-bridge`, indem Sie Folgendes in Ihrer `config/overleaf.rc` festlegen:

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

Das Toolkit ignoriert diese Einstellung, sofern nicht zusätzlich `SERVER_PRO=true` gesetzt ist. Mehr ist nicht nötig: Das Toolkit setzt `GIT_BRIDGE_HOST`, `GIT_BRIDGE_PORT` und `V1_HISTORY_URL` für den `sharelatex`-Container selbst, überspringen Sie daher die beiden folgenden Docker-Compose-Schritte. Führen Sie `bin/up` aus, um die Container neu zu erstellen.

**2. git-bridge-Container hinzufügen (nur für Docker-Compose-Nutzer)**

Wenn Sie eine eigene `docker-compose.yml` verwenden, fügen Sie Ihrer Compose-Datei die folgende Container-Konfiguration hinzu:

```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"]
```

Verwenden Sie dasselbe Tag wie für das `sharelatex`-Image. Der [MCP-Server](https://ayakaleaf-pro.mintlify.site/de/on-premises/configuration/overleaf-toolkit/integrations/mcp-server.md) (v6.3.1 und neuer) ist Teil des `sharelatex`-Images und wird zusammen mit der Git-Integration aktiviert, sodass er keinen zusätzlichen Container benötigt.

**3. Konfiguration des sharelatex-Containers aktualisieren**

Außerdem müssen Sie den Container `git-bridge` im Container `sharelatex` verlinken und die folgenden Umgebungsvariablen definieren. Achten Sie dabei besonders auf `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. Authentifizierung**

Zur Authentifizierung eines Git-Clients benötigen Nutzerinnen und Nutzer ein Personal Access Token. Personal Access Tokens können über die Benutzeroberfläche der Anwendung verwaltet werden (siehe Dokumentation):

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

Personal Access Token für die Git-Integration

**5. Überwachung und Ressourcenbedarf**

Wir empfehlen, nach der Aktivierung der `git-bridge` die Ressourcen Ihres Hosts zu überwachen. Die zusätzliche Last hängt ab von:

* der Anzahl der Nutzerinnen und Nutzer, die die Funktion verwenden
* der Art der in Ihrer Instanz gehosteten Projekte (größere Projekte sind in der Regel ressourcenintensiver)

### Projekte nach S3 auslagern

Die Git-Integration speichert für jedes Projekt, das von einem Benutzer geklont wird, ein vollständiges Git-Repository auf der Festplatte. Wenn Ihr Speicherplatz begrenzt ist, können Sie einen Swap-Job aktivieren, der weniger genutzte Repositories nach AWS S3 verschiebt. Wird ein ausgelagertes Repository wieder benötigt, wird es zurück auf die Festplatte verschoben. Die folgenden Umgebungsvariablen steuern den Swap-Job:

| Name | Beschreibung |
| - | - |
| `GIT_BRIDGE_SWAPSTORE_TYPE` | Setzen Sie diesen Wert auf "s3", um den Swap-Job zu aktivieren. |
| `GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY` | Ihr AWS Access Key |
| `GIT_BRIDGE_SWAPSTORE_AWS_SECRET` | Ihr AWS Secret |
| `GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME` | Dieser Bucket enthält die gezippten Git-Repositories |
| `GIT_BRIDGE_SWAPSTORE_AWS_REGION` | Die Region des Buckets |
| `GIT_BRIDGE_SWAPJOB_MIN_PROJECTS` | Mindestanzahl der Projekte, die auf der Festplatte verbleiben. **- Standard:** 50 |
| `GIT_BRIDGE_SWAPJOB_LOW_GIB` | Untere Schwelle für das Auslagern. Der Swap-Job verschiebt Projekte, bis die Festplattennutzung unter diesem Wert liegt. **- Standard:** 128 GB |
| `GIT_BRIDGE_SWAPJOB_HIGH_GIB` | Obere Schwelle für das Auslagern. Der Swap-Job beginnt mit dem Auslagern, wenn die Festplattennutzung diesen Wert erreicht. **- Standard:** 256 GB |
| `GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS` | Zeitabstand zwischen der Prüfung der Festplattennutzung und der Ausführung des Swap-Jobs. **- Standard:** 3600000 ms = 1 Stunde |

### Fragen und Antworten

> [accordion] Wie funktioniert das Berechtigungsmodell der Git Bridge, wenn ich mein Projekt mit anderen teile?
>
> Nutzerinnen und Nutzer mit Lesezugriff können dieses Projekt nur klonen; Nutzerinnen und Nutzer mit Lese- und Schreibzugriff können Projekte klonen und pushen. Hinweis: Nutzerinnen und Nutzer müssen angemeldet sein, um diesem Projekt beizutreten.

> [accordion] Wie klone ich ein Projekt, und welchen Benutzernamen und welches Passwort verwende ich?
>
> Öffnen Sie im Editor in der linken Leiste **Integrations** und klicken Sie auf **Git integration**. Dort wird der Clone-Befehl in folgender Form angezeigt:
>
> ```sh theme={null}
> git clone https://<your-overleaf>/git/<project_id>
> ```
>
> Wenn Git nach Zugangsdaten fragt, geben Sie `git` als Benutzernamen und ein Personal Access Token als Passwort ein. Erzeugen Sie das Token unter **Account Settings**; es ist ein Jahr lang gültig. Ihr Kontopasswort funktioniert nicht.
>
> Änderungen werden nicht automatisch synchronisiert: Verwenden Sie `git pull`, um die im Editor vorgenommenen Änderungen abzurufen, und `git push`, um Ihre eigenen zu übertragen. Der Pfad `/git` wird vom `sharelatex`-Container bereitgestellt, daher benötigt ein vorgeschalteter Reverse Proxy keine zusätzliche Regel.

> [accordion] `git push` schlägt mit `HTTP 413` oder `curl 55 Broken pipe` fehl
>
> Der Push ist größer als das Upload-Limit, das über `MAX_UPLOAD_SIZE` festgelegt wird (in Megabyte, standardmäßig `50`) und auch für Pushes gilt. Erhöhen Sie es in `config/variables.env`, zum Beispiel auf `MAX_UPLOAD_SIZE=200`, und führen Sie dann `bin/up -d` aus. Wenn Sie den [TLS-Proxy](https://ayakaleaf-pro.mintlify.site/de/on-premises/configuration/overleaf-toolkit/tls-proxy.md) oder Ihren eigenen Reverse Proxy verwenden, erhöhen Sie auch dessen `client_max_body_size` (`50M` in der `config/nginx/nginx.conf` des Toolkits).
>
> Die git-bridge lehnt außerdem Dateien größer als 50 MB und Projekte mit mehr als 2.000 Dateien ab. Diese Limits werden über `GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE` (in Byte) und `GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM` in `config/variables.env` festgelegt.

> [accordion] Das git-bridge-Log zeigt `Failed to fetch log level`
>
> Die Warnung ist harmlos, und Clone, Pull und Push funktionieren weiterhin. In 6.2.x fragt die git-bridge einmal pro Minute beim Google-Cloud-Metadatenserver (`metadata.google.internal`) eine Log-Stufe ab, was nur auf Google Cloud funktioniert. Anderswo schlägt die Anfrage fehl, die git-bridge protokolliert den Fehler (etwa `null` oder einen HTTP-Status) und behält die Stufe aus `GIT_BRIDGE_LOG_LEVEL` bei. Ab 6.3.0 ist die Prüfung deaktiviert, und ein Upgrade aktualisiert auch das git-bridge-Image, dessen Version dem Hauptimage folgt.

> [accordion] Benötige ich den track-changes-Dienst oder `OVERLEAF_IS_SERVER_PRO=true` für Git und den vollständigen Projektverlauf?
>
> **Antwort:** Nein. Ayakaleaf Pro hat keinen track-changes-Dienst. Der Projektverlauf wird von den Diensten `project-history` und `history-v1` verwaltet, die immer im `sharelatex`-Container laufen. Die git-bridge liest den Verlauf aus `history-v1` unter `V1_HISTORY_URL` (`http://sharelatex:3100/api`), das vom Toolkit gesetzt wird. Setzen Sie `OVERLEAF_IS_SERVER_PRO` nicht: Keine Funktion hängt davon ab, die Variable stellt lediglich die beim Start ausgeführten Datenbankmigrationen auf die Server-Pro-Variante um.


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