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

> La brukere klone, hente og pushe prosjektene sine med Git via git-bridge.

Git-integrasjonen er foreløpig tilgjengelig i [ayaka-notes/overleaf](https://github.com/ayaka-notes/overleaf).

> [!NOTE]
>
> Denne funksjonen ble opprinnelig utviklet av [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro).

**1. Aktiver git-bridge (kun for Toolkit-brukere)**

Hvis du bruker Toolkit, aktiverer du `git-bridge` ved å angi følgende i `config/overleaf.rc`:

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

Toolkit ignorerer den med mindre `SERVER_PRO=true` også er satt. Ingenting annet trengs: Toolkit setter selv `GIT_BRIDGE_HOST`, `GIT_BRIDGE_PORT` og `V1_HISTORY_URL` for `sharelatex`-containeren, så hopp over de to Docker Compose-trinnene nedenfor. Kjør `bin/up` for å gjenopprette containerne.

**2. Legg til git-bridge-containeren (kun for Docker-compose-brukere)**

Brukere som kjører en egendefinert `docker-compose.yml`, legger til følgende containerkonfigurasjon i compose-filen sin:

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

Bruk samme tag som `sharelatex`-imaget. [MCP-serveren](https://ayakaleaf-pro.mintlify.site/no/on-premises/configuration/overleaf-toolkit/integrations/mcp-server.md) (v6.3.1 og nyere) er en del av `sharelatex`-imaget og aktiveres sammen med Git-integrasjonen, så den trenger ingen ekstra container.

**3. Oppdater konfigurasjonen av sharelatex-containeren**

Du må også koble `git-bridge`-containeren til `sharelatex`-containeren og definere følgende miljøvariabler. Vær spesielt oppmerksom på `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. Autentisering**

Ved autentisering av en git-klient trenger brukerne et personlig tilgangstoken (Personal Access Token). Brukerne kan administrere personlige tilgangstokener i applikasjonens brukergrensesnitt (se dokumentasjonen):

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

Personlig tilgangstoken for Git-integrasjon

**5. Overvåking og ressurshensyn**

Vi anbefaler at du overvåker ressursene på verten etter at du har aktivert `git-bridge`. Økningen i belastning avhenger av:

* antall brukere som bruker funksjonen
* hvilke typer prosjekter som ligger i instansen din (større prosjekter krever generelt mer ressurser)

### Flytte prosjekter til S3 (swap)

Git-integrasjonen lagrer et komplett git-repository på disk for hvert prosjekt som en bruker kloner. Hvis du har begrenset diskplass, kan du aktivere en swap-jobb som flytter repositorier som brukes sjeldnere, til AWS S3. Hvis et flyttet repository trengs igjen, flyttes det tilbake til disken. Følgende miljøvariabler styrer swap-jobben:

| Navn | Beskrivelse |
| - | - |
| `GIT_BRIDGE_SWAPSTORE_TYPE` | Sett denne til "s3" for å aktivere swap-jobben. |
| `GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY` | AWS-tilgangsnøkkelen din |
| `GIT_BRIDGE_SWAPSTORE_AWS_SECRET` | AWS-hemmeligheten din |
| `GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME` | Denne bucketen vil inneholde de zippede git-repositoriene |
| `GIT_BRIDGE_SWAPSTORE_AWS_REGION` | Bucketens region |
| `GIT_BRIDGE_SWAPJOB_MIN_PROJECTS` | Minste antall prosjekter som skal beholdes på disk. **- Standard:** 50 |
| `GIT_BRIDGE_SWAPJOB_LOW_GIB` | Nedre terskel for swapping. Swap-jobben flytter prosjekter til diskbruken er under denne verdien. **- Standard:** 128 GB |
| `GIT_BRIDGE_SWAPJOB_HIGH_GIB` | Øvre terskel for swapping. Swap-jobben begynner å flytte når diskbruken når denne verdien. **- Standard:** 256 GB |
| `GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS` | Tiden mellom hver kontroll av diskbruk og kjøring av swap-jobben. **- Standard:** 3600000 ms = 1 time |

### Spørsmål og svar

> [accordion] Hvis jeg deler prosjektet mitt med noen andre, hvordan fungerer tillatelsesmodellen i Git Bridge?
>
> Brukere med skrivebeskyttet tilgang kan bare klone prosjektet; brukere med lese- og skrivetilgang kan klone og pushe prosjekter. Merk: Brukerne må være logget inn for å bli med i prosjektet.

> [accordion] Hvordan kloner jeg et prosjekt, og hvilket brukernavn og passord bruker jeg?
>
> I editoren åpner du **Integrations** i venstre felt og klikker **Git integration**. Der vises klonekommandoen, på formen:
>
> ```sh theme={null}
> git clone https://<your-overleaf>/git/<project_id>
> ```
>
> Når Git ber om legitimasjon, skriver du inn `git` som brukernavn og et personlig tilgangstoken (Personal Access Token) som passord. Generer tokenet i **Account Settings**; det er gyldig i ett år. Kontopassordet ditt fungerer ikke.
>
> Endringer synkroniseres ikke automatisk: bruk `git pull` for å hente endringene som er gjort i editoren, og `git push` for å sende dine. Stien `/git` serveres av `sharelatex`-containeren, så en reverse proxy foran den trenger ingen ekstra regel.

> [accordion] `git push` mislykkes med `HTTP 413` eller `curl 55 Broken pipe`
>
> Pushen er større enn grensen for opplastingsstørrelse, som angis med `MAX_UPLOAD_SIZE` (i megabyte, `50` som standard) og også gjelder for push. Øk den i `config/variables.env`, for eksempel `MAX_UPLOAD_SIZE=200`, og kjør deretter `bin/up -d`. Hvis du bruker [TLS-proxyen](https://ayakaleaf-pro.mintlify.site/no/on-premises/configuration/overleaf-toolkit/tls-proxy.md) eller din egen reverse proxy, må du også øke `client_max_body_size` der (`50M` i Toolkits `config/nginx/nginx.conf`).
>
> Git-bridge avviser også filer større enn 50 MB og prosjekter med mer enn 2 000 filer. Disse grensene angis med `GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE` (i byte) og `GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM` i `config/variables.env`.

> [accordion] Git-bridge-loggen viser `Failed to fetch log level`
>
> Advarselen er ufarlig, og clone, pull og push fortsetter å fungere. I 6.2.x spør git-bridge metadataserveren til Google Cloud (`metadata.google.internal`) om et loggnivå én gang i minuttet, noe som bare fungerer på Google Cloud. Andre steder mislykkes forespørselen, git-bridge logger feilen (for eksempel `null` eller en HTTP-status) og beholder nivået fra `GIT_BRIDGE_LOG_LEVEL`. Fra og med 6.3.0 er sjekken slått av, og en oppgradering oppdaterer også git-bridge-imaget, hvis versjon følger hovedimaget.

> [accordion] Trenger jeg track-changes-tjenesten eller `OVERLEAF_IS_SERVER_PRO=true` for Git og full prosjekthistorikk?
>
> **Svar:** Nei. Ayakaleaf Pro har ingen track-changes-tjeneste. Prosjekthistorikken håndteres av tjenestene `project-history` og `history-v1`, som alltid kjører inne i `sharelatex`-containeren. Git-bridge leser historikk fra `history-v1` på `V1_HISTORY_URL` (`http://sharelatex:3100/api`), som Toolkit setter. Ikke sett `OVERLEAF_IS_SERVER_PRO`: ingen funksjon er avhengig av den, den bytter bare databasemigreringene som kjøres ved oppstart, til Server Pro-settet.


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