> ## 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. # Integracja z Git > Pozwól użytkownikom klonować, pobierać i wypychać projekty za pomocą Git przez git-bridge. Integracja z Git jest obecnie dostępna w [ayaka-notes/overleaf](https://github.com/ayaka-notes/overleaf). > [!NOTE] > > Ta funkcja została pierwotnie opracowana przez [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro). **1. Włącz git-bridge (tylko dla użytkowników Toolkit)** Jeśli używasz Toolkit, włącz `git-bridge`, ustawiając w pliku `config/overleaf.rc`: ```text title="config/overleaf.rc" theme={null} GIT_BRIDGE_ENABLED=true ``` Toolkit ignoruje to ustawienie, jeśli nie ustawiono również `SERVER_PRO=true`. Nic więcej nie jest potrzebne: Toolkit sam ustawia `GIT_BRIDGE_HOST`, `GIT_BRIDGE_PORT` i `V1_HISTORY_URL` dla kontenera `sharelatex`, więc pomiń dwa poniższe kroki dotyczące Docker Compose. Uruchom `bin/up`, aby odtworzyć kontenery. **2. Dodaj kontener git-bridge (tylko dla użytkowników Docker Compose)** Jeśli używasz własnego pliku `docker-compose.yml`, dodaj do niego następującą konfigurację kontenera: ```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"] ``` Użyj tego samego tagu co obraz `sharelatex`. [Serwer MCP](https://ayakaleaf-pro.mintlify.site/pl/on-premises/configuration/overleaf-toolkit/integrations/mcp-server.md) (v6.3.1 i nowsze) jest częścią obrazu `sharelatex` i jest włączany razem z integracją z Git, więc nie wymaga dodatkowego kontenera. **3. Zaktualizuj konfigurację kontenera sharelatex** Musisz również powiązać kontener `git-bridge` z kontenerem `sharelatex` i zdefiniować poniższe zmienne środowiskowe. Zwróć szczególną uwagę na `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. Uwierzytelnianie** Do uwierzytelnienia klienta git użytkownicy potrzebują osobistego tokenu dostępu (Personal Access Token). Użytkownicy mogą zarządzać osobistymi tokenami dostępu w interfejsie aplikacji (zobacz dokumentację): ![](https://mintcdn.com/ayakaleaf-pro/UZ_4Jfz7cU6MnXtE/images/on-premises/image-29.png?fit=max\&auto=format\&n=UZ_4Jfz7cU6MnXtE\&q=85\&s=39af379b36baaa023f7cff66dc2dba76) Osobisty token dostępu dla integracji z Git **5. Monitorowanie i zasoby** Po włączeniu `git-bridge` zalecamy monitorowanie zasobów hosta. Wzrost obciążenia będzie zależał od: * liczby użytkowników korzystających z tej funkcji * rodzajów projektów hostowanych w Twojej instancji (większe projekty zazwyczaj wymagają więcej zasobów) ### Przenoszenie projektów do S3 Integracja z Git przechowuje na dysku kompletne repozytorium git dla każdego projektu sklonowanego przez użytkownika. Jeśli masz ograniczoną przestrzeń dyskową, możesz aktywować zadanie wymiany (swap), które przeniesie rzadziej używane repozytoria do AWS S3. Gdy przeniesione repozytorium będzie ponownie potrzebne, zostanie przywrócone na dysk. Zadanie wymiany kontrolują następujące zmienne środowiskowe: | Nazwa | Opis | | - | - | | `GIT_BRIDGE_SWAPSTORE_TYPE` | Ustaw na "s3", aby aktywować zadanie wymiany. | | `GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY` | Twój klucz dostępu AWS | | `GIT_BRIDGE_SWAPSTORE_AWS_SECRET` | Twój sekret AWS | | `GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME` | Ten bucket będzie zawierał spakowane repozytoria git | | `GIT_BRIDGE_SWAPSTORE_AWS_REGION` | Region bucketu | | `GIT_BRIDGE_SWAPJOB_MIN_PROJECTS` | Minimalna liczba projektów przechowywanych na dysku. **- Domyślnie:** 50 | | `GIT_BRIDGE_SWAPJOB_LOW_GIB` | Dolny próg wymiany. Zadanie wymiany będzie przenosić projekty, dopóki zajętość dysku nie spadnie poniżej tej wartości. **- Domyślnie:** 128 GB | | `GIT_BRIDGE_SWAPJOB_HIGH_GIB` | Górny próg wymiany. Zadanie wymiany rozpocznie przenoszenie, gdy zajętość dysku osiągnie tę wartość. **- Domyślnie:** 256 GB | | `GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS` | Odstęp czasu między sprawdzeniem zajętości dysku a uruchomieniem zadania wymiany. **- Domyślnie:** 3600000 ms = 1 godzina | ### Pytania i odpowiedzi > [accordion] Jak działa model uprawnień Git Bridge, jeśli udostępnię projekt komuś innemu? > > Użytkownicy z dostępem tylko do odczytu mogą jedynie klonować projekt; użytkownicy z dostępem do odczytu i zapisu mogą klonować projekty i wypychać do nich zmiany. Uwaga: aby dołączyć do projektu, użytkownicy muszą być zalogowani. > [accordion] Jak sklonować projekt i jakiej nazwy użytkownika oraz hasła użyć? > > W edytorze otwórz **Integrations** na lewym pasku i kliknij **Git integration**. Zostanie wyświetlone polecenie klonowania w postaci: > > ```sh theme={null} > git clone https:///git/ > ``` > > Gdy Git poprosi o dane uwierzytelniające, wpisz `git` jako nazwę użytkownika i Personal Access Token jako hasło. Wygeneruj token w **Account Settings**; jest ważny przez jeden rok. Hasło do konta nie zadziała. > > Zmiany nie są synchronizowane automatycznie: użyj `git pull`, aby pobrać zmiany wprowadzone w edytorze, oraz `git push`, aby wysłać własne. Ścieżka `/git` jest obsługiwana przez kontener `sharelatex`, więc reverse proxy umieszczone przed nim nie wymaga dodatkowej reguły. > [accordion] `git push` kończy się błędem `HTTP 413` lub `curl 55 Broken pipe` > > Wypychane dane przekraczają limit rozmiaru przesyłanych plików, ustawiany przez `MAX_UPLOAD_SIZE` (w megabajtach, domyślnie `50`), który dotyczy również operacji push. Zwiększ go w `config/variables.env`, na przykład `MAX_UPLOAD_SIZE=200`, a następnie uruchom `bin/up -d`. Jeśli używasz [proxy TLS](https://ayakaleaf-pro.mintlify.site/pl/on-premises/configuration/overleaf-toolkit/tls-proxy.md) lub własnego reverse proxy, zwiększ także jego `client_max_body_size` (`50M` w pliku `config/nginx/nginx.conf` w Toolkit). > > git-bridge odrzuca również pliki większe niż 50 MB oraz projekty zawierające ponad 2000 plików. Limity te ustawiają zmienne `GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE` (w bajtach) i `GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM` w `config/variables.env`. > [accordion] Log git-bridge pokazuje `Failed to fetch log level` > > To ostrzeżenie jest nieszkodliwe, a klonowanie, pobieranie i wypychanie nadal działają. W wersjach 6.2.x git-bridge raz na minutę pyta serwer metadanych Google Cloud (`metadata.google.internal`) o poziom logowania, co działa tylko w Google Cloud. W innych środowiskach żądanie kończy się niepowodzeniem, git-bridge zapisuje błąd w logu (np. `null` lub kod statusu HTTP) i zachowuje poziom z `GIT_BRIDGE_LOG_LEVEL`. Od wersji 6.3.0 to sprawdzanie jest wyłączone, a aktualizacja aktualizuje również obraz git-bridge, którego wersja odpowiada obrazowi głównemu. > [accordion] Czy potrzebuję usługi track-changes lub `OVERLEAF_IS_SERVER_PRO=true` dla Git i pełnej historii projektu? > > **Odpowiedź:** Nie. Ayakaleaf Pro nie ma usługi track-changes. Historię projektu przechowują usługi `project-history` i `history-v1`, które zawsze działają w kontenerze `sharelatex`. git-bridge odczytuje historię z `history-v1` pod adresem `V1_HISTORY_URL` (`http://sharelatex:3100/api`), który ustawia Toolkit. Nie ustawiaj `OVERLEAF_IS_SERVER_PRO`: żadna funkcja od niej nie zależy, a jedynie przełącza migracje bazy danych uruchamiane przy starcie na zestaw Server Pro. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.