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 verfügbar.

Diese Funktion wurde ursprünglich von 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:

   config/overleaf.rc

   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:

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

   Verwenden Sie dasselbe Tag wie für das sharelatex-Image. Der MCP-Server (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:

   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)

​

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

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.

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:

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.

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

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.

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.