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

> Låt användare klona, hämta och pusha sina projekt med Git via git-bridge.

Git-integrationen är för närvarande tillgänglig i [ayaka-notes/overleaf](https://github.com/ayaka-notes/overleaf).

> [!NOTE]
>
> Den här funktionen utvecklades ursprungligen av [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro).

**1. Aktivera git-bridge (endast för Toolkit-användare)**

Om du använder Toolkit aktiverar du `git-bridge` genom att ange följande i din `config/overleaf.rc`:

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

Toolkit ignorerar den om inte även `SERVER_PRO=true` är satt. Inget mer behövs: Toolkit sätter själv `GIT_BRIDGE_HOST`, `GIT_BRIDGE_PORT` och `V1_HISTORY_URL` för containern `sharelatex`, så hoppa över de två Docker Compose-stegen nedan. Kör `bin/up` för att återskapa containrarna.

**2. Lägg till git-bridge-containern (endast för Docker-compose-användare)**

Användare som kör en egen `docker-compose.yml` lägger till följande containerkonfiguration i sin compose-fil:

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

Använd samma tagg som för `sharelatex`-imagen. [MCP-servern](https://ayakaleaf-pro.mintlify.site/sv/on-premises/configuration/overleaf-toolkit/integrations/mcp-server.md) (v6.3.1 och senare) ingår i `sharelatex`-imagen och aktiveras tillsammans med Git-integrationen, så den behöver ingen extra container.

**3. Uppdatera konfigurationen för sharelatex-containern**

Du behöver också länka `git-bridge`-containern i `sharelatex`-containern och definiera följande miljövariabler. Var särskilt uppmärksam 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**

När en git-klient ska autentiseras behöver användarna en personlig åtkomsttoken (Personal Access Token). Användarna kan hantera sina personliga åtkomsttoken via applikationens gränssnitt (se dokumentationen):

![](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 åtkomsttoken för Git-integrationen

**5. Övervakning och resursöverväganden**

Vi rekommenderar att du övervakar värdens resurser efter att du har aktiverat `git-bridge`. Hur mycket belastningen ökar beror på:

* antalet användare som använder funktionen
* vilka typer av projekt som finns i din instans (större projekt är i allmänhet mer resurskrävande)

### Flytta projekt till S3

Git-integrationen lagrar ett fullständigt git-repository på disk för varje projekt som klonas av en användare. Om du har begränsat diskutrymme kan du aktivera ett swap-jobb som flyttar mindre använda repositories till AWS S3. Om ett utflyttat repository behövs igen flyttas det tillbaka till disken. Följande miljövariabler styr swap-jobbet:

| Namn | Beskrivning |
| - | - |
| `GIT_BRIDGE_SWAPSTORE_TYPE` | Ange "s3" för att aktivera swap-jobbet. |
| `GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY` | Din AWS-åtkomstnyckel |
| `GIT_BRIDGE_SWAPSTORE_AWS_SECRET` | Din AWS-hemlighet |
| `GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME` | Den här bucketen kommer att innehålla de zippade git-repositoryna |
| `GIT_BRIDGE_SWAPSTORE_AWS_REGION` | Bucketens region |
| `GIT_BRIDGE_SWAPJOB_MIN_PROJECTS` | Minsta antal projekt som ska behållas på disk. **- Standard:** 50 |
| `GIT_BRIDGE_SWAPJOB_LOW_GIB` | Lägre gränsvärde för swapping. Swap-jobbet flyttar projekt tills diskanvändningen understiger detta värde. **- Standard:** 128 GB |
| `GIT_BRIDGE_SWAPJOB_HIGH_GIB` | Övre gränsvärde för swapping. Swap-jobbet börjar flytta projekt när diskanvändningen når detta värde. **- Standard:** 256 GB |
| `GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS` | Tiden mellan kontrollerna av diskanvändningen och körningarna av swap-jobbet. **- Standard:** 3600000 ms = 1 timme |

### Frågor och svar

> [accordion] Hur fungerar behörighetsmodellen i Git Bridge om jag delar mitt projekt med någon annan?
>
> Användare med skrivskyddad åtkomst kan endast klona projektet; användare med läs- och skrivåtkomst kan både klona och pusha projekt. Obs! Användarna måste vara inloggade för att gå med i projektet.

> [accordion] Hur klonar jag ett projekt, och vilket användarnamn och lösenord ska jag använda?
>
> I redigeraren öppnar du **Integrations** i den vänstra listen och klickar på **Git integration**. Där visas klonkommandot, på formen:
>
> ```sh theme={null}
> git clone https://<your-overleaf>/git/<project_id>
> ```
>
> När Git frågar efter inloggningsuppgifter anger du `git` som användarnamn och en personlig åtkomsttoken (Personal Access Token) som lösenord. Generera token under **Account Settings**; den är giltig i ett år. Ditt kontolösenord fungerar inte.
>
> Ändringar synkroniseras inte automatiskt: använd `git pull` för att hämta ändringarna som gjorts i redigeraren och `git push` för att skicka dina. Sökvägen `/git` serveras av `sharelatex`-containern, så en omvänd proxy framför den behöver ingen extra regel.

> [accordion] `git push` misslyckas med `HTTP 413` eller `curl 55 Broken pipe`
>
> Pushen är större än gränsen för uppladdningsstorlek, som anges med `MAX_UPLOAD_SIZE` (i megabyte, `50` som standard) och även gäller för pushar. Höj den i `config/variables.env`, till exempel `MAX_UPLOAD_SIZE=200`, och kör sedan `bin/up -d`. Om du använder [TLS-proxyn](https://ayakaleaf-pro.mintlify.site/sv/on-premises/configuration/overleaf-toolkit/tls-proxy.md) eller en egen omvänd proxy höjer du även dess `client_max_body_size` (`50M` i Toolkits `config/nginx/nginx.conf`).
>
> git-bridge avvisar även filer större än 50 MB och projekt med fler än 2 000 filer. Dessa gränser anges med `GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE` (i byte) och `GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM` i `config/variables.env`.

> [accordion] git-bridge-loggen visar `Failed to fetch log level`
>
> Varningen är ofarlig, och clone, pull och push fortsätter att fungera. I 6.2.x frågar git-bridge Google Clouds metadataserver (`metadata.google.internal`) efter en loggnivå en gång i minuten, vilket bara fungerar på Google Cloud. På andra ställen misslyckas förfrågan, git-bridge loggar felet (till exempel `null` eller en HTTP-status) och behåller nivån från `GIT_BRIDGE_LOG_LEVEL`. Från 6.3.0 är kontrollen avstängd, och en uppgradering uppdaterar även git-bridge-imagen, vars version följer huvudimagen.

> [accordion] Behöver jag tjänsten track-changes eller `OVERLEAF_IS_SERVER_PRO=true` för Git och fullständig projekthistorik?
>
> **Svar:** Nej. Ayakaleaf Pro har ingen track-changes-tjänst. Projekthistoriken hanteras av tjänsterna `project-history` och `history-v1`, som alltid körs inuti containern `sharelatex`. git-bridge läser historiken från `history-v1` på `V1_HISTORY_URL` (`http://sharelatex:3100/api`), som Toolkit sätter. Sätt inte `OVERLEAF_IS_SERVER_PRO`: ingen funktion är beroende av den, den växlar bara de databasmigreringar som körs vid start till uppsättningen för Server Pro.


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