De git-bridge inschakelen (alleen voor Toolkit-gebruikers)
Als je de Toolkit gebruikt, schakel je de git-bridge in door het volgende in te stellen in je config/overleaf.rc:
config/overleaf.rc
GIT_BRIDGE_ENABLED=true
2
De git-bridge-container toevoegen (alleen voor Docker Compose-gebruikers)
Gebruikers met een eigen docker-compose.yml voegen de volgende containerconfiguratie toe aan hun compose-bestand:
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
De configuratie van de sharelatex-container bijwerken
Je moet ook de container git-bridge koppelen in de container sharelatex en de volgende omgevingsvariabelen definiëren; let daarbij goed op 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
Authenticatie
Bij het authenticeren van een git-client hebben gebruikers een Personal Access Token nodig. Gebruikers kunnen Personal Access Tokens beheren via de gebruikersinterface van de applicatie (zie de documentatie):
Personal Access Token voor de Git-integratie
5
Monitoring en resources
We raden aan de resources van je host te monitoren nadat je de git-bridge hebt ingeschakeld. De toename van de belasting hangt af van:
het aantal gebruikers dat de functie gebruikt
de soorten projecten die op je instantie worden gehost (grotere projecten vragen over het algemeen meer resources)
De Git-integratie slaat voor elk project dat door een gebruiker wordt gekloond een volledige git-repository op schijf op. Als je beperkte schijfruimte hebt, kun je een swap-job activeren die minder gebruikte repository’s naar AWS S3 verplaatst. Als een geswapte repository opnieuw nodig is, wordt deze teruggezet naar de schijf. De volgende omgevingsvariabelen bepalen de swap-job:
Naam
Beschrijving
GIT_BRIDGE_SWAPSTORE_TYPE
Stel dit in op “s3” om de swap-job te activeren.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY
Je AWS-toegangssleutel
GIT_BRIDGE_SWAPSTORE_AWS_SECRET
Je AWS-secret
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME
Deze bucket bevat de gezipte git-repository’s
GIT_BRIDGE_SWAPSTORE_AWS_REGION
De regio van de bucket
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS
Hoeveel projecten er minimaal op schijf moeten blijven.
- Standaard: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB
Lage drempel voor swappen. De swap-job verplaatst projecten totdat het schijfgebruik onder deze waarde ligt.
- Standaard: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB
Hoge drempel voor swappen. De swap-job begint met swappen wanneer het schijfgebruik deze waarde bereikt.
- Standaard: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS
De tijd tussen het controleren van het schijfgebruik en het uitvoeren van de swap-job.
Als ik mijn project met iemand anders deel, hoe werkt dan het rechtenmodel van de Git Bridge?
Gebruikers met alleen-lezentoegang kunnen dit project alleen klonen; gebruikers met lees- en schrijftoegang kunnen projecten klonen en pushen. Let op: gebruikers moeten aangemeld zijn om aan dit project deel te nemen.
Laatst gewijzigd op 5 oktober 2026
Was deze pagina nuttig?
Assistant
Responses are generated using AI and may contain mistakes.