Wenn Sie das Toolkit verwenden, aktivieren Sie die git-bridge, indem Sie Folgendes in Ihrer config/overleaf.rc festlegen:
config/overleaf.rc
GIT_BRIDGE_ENABLED=true
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:
docker-compose.yml (git-bridge service)
git-bridge: restart: always image: ghcr.io/ayaka-notes/overleaf-pro/git-bridge:6.3.0 # 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/" # "http://sharelatex/api/v0/" for version 4.1.6 and earlier 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"]
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:
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
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):
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)
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.
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.
Zuletzt geändert am 5. Oktober 2026
War diese Seite hilfreich?
Assistant
Responses are generated using AI and may contain mistakes.