Git entegrasyonu

Kullanıcıların git-bridge aracılığıyla projelerini Git ile klonlamasını, çekmesini ve göndermesini sağlayın.

Git entegrasyonu şu anda ayaka-notes/overleaf üzerinde mevcuttur.

Bu özellik başlangıçta ayaka-notes/ayakaleaf-pro tarafından geliştirilmiştir.

1. git-bridge'i etkinleştirin (Yalnızca Toolkit kullanıcıları için)

   Toolkit kullanıyorsanız config/overleaf.rc dosyanızda aşağıdakini ayarlayarak git-bridge’i etkinleştirin:

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   Toolkit, SERVER_PRO=true de ayarlanmadıkça bunu yok sayar. Başka bir şey gerekmez: Toolkit, sharelatex konteyneri için GIT_BRIDGE_HOST, GIT_BRIDGE_PORT ve V1_HISTORY_URL değerlerini kendisi ayarlar; bu nedenle aşağıdaki iki Docker Compose adımını atlayın. Konteynerleri yeniden oluşturmak için bin/up komutunu çalıştırın.

2. git-bridge konteynerini ekleyin (Yalnızca Docker-compose kullanıcıları için)

   Özel bir docker-compose.yml çalıştıran kullanıcılar, aşağıdaki konteyner yapılandırmasını compose dosyalarına eklemelidir:

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

   sharelatex imajıyla aynı etiketi kullanın. MCP Server (v6.3.1 ve sonrası) sharelatex imajının bir parçasıdır ve Git entegrasyonuyla birlikte etkinleştirilir; bu nedenle ek bir konteyner gerektirmez.

3. sharelatex konteyner yapılandırmasını güncelleyin

   Ayrıca git-bridge konteynerini sharelatex konteynerine bağlamanız ve aşağıdaki ortam değişkenlerini tanımlamanız gerekir; lütfen V1_HISTORY_URL değişkenine dikkat edin:

   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. Kimlik doğrulama

   Bir git istemcisinin kimliğini doğrularken kullanıcıların bir Kişisel Erişim Belirtecine (Personal Access Token) ihtiyacı vardır. Kullanıcılar Kişisel Erişim Belirteçlerini uygulama arayüzü üzerinden yönetebilir (belgelere bakın):

   

   Git Entegrasyonu Kişisel Erişim Belirteci

5. İzleme ve kaynak hususları

   git-bridge’i etkinleştirdikten sonra ana makine kaynaklarınızı izlemenizi öneririz. Yük artışı şunlara bağlı olacaktır:

   • özelliğe erişen kullanıcı sayısı
   • kurulumunuzda barındırılan projelerin türleri (daha büyük projeler genellikle daha fazla kaynak tüketir)

​

Projeleri S3’e taşıma (swap)

Git entegrasyonu, bir kullanıcı tarafından klonlanan her proje için diskte eksiksiz bir git deposu depolar. Disk alanınız sınırlıysa, daha az kullanılan depoları AWS S3’e taşıyacak bir swap işini etkinleştirebilirsiniz. Taşınmış bir depoya yeniden ihtiyaç duyulursa diske geri taşınır. Aşağıdaki ortam değişkenleri swap işini kontrol eder:

Ad	Açıklama
GIT_BRIDGE_SWAPSTORE_TYPE	Swap işini etkinleştirmek için bunu “s3” olarak ayarlayın.
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	AWS erişim anahtarınız
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	AWS gizli anahtarınız
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	Bu bucket, sıkıştırılmış (zip) git depolarını içerecektir
GIT_BRIDGE_SWAPSTORE_AWS_REGION	Bucket’ın bölgesi
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	Diskte en az kaç proje tutulacağı. - Varsayılan: 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	Swap için alt eşik değeri. Swap işi, disk kullanımı bu değerin altına inene kadar projeleri taşır. - Varsayılan: 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	Swap için üst eşik değeri. Swap işi, disk kullanımı bu değere ulaştığında taşımaya başlar. - Varsayılan: 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	Disk kullanımının kontrol edilmesi ve swap işinin çalıştırılması arasındaki süre. - Varsayılan: 3600000 ms = 1 saat

​

S&C

Projemi başka biriyle paylaşırsam Git Bridge izin modeli nasıl çalışır?

Salt okunur erişime sahip kullanıcılar bu projeyi yalnızca klonlayabilir; okuma-yazma erişimine sahip kullanıcılar projeleri klonlayabilir ve push edebilir. Not: Kullanıcıların bu projeye katılmak için oturum açmış olması gerekir.

Bir projeyi nasıl klonlarım ve hangi kullanıcı adı ile parolayı kullanırım?

Düzenleyicide sol çubuktaki Integrations bölümünü açın ve Git integration öğesine tıklayın. Burada klonlama komutu şu biçimde gösterilir:

git clone https://<your-overleaf>/git/<project_id>

Git kimlik bilgilerini istediğinde kullanıcı adı olarak git, parola olarak da bir Kişisel Erişim Token’ı (Personal Access Token) girin. Token’ı Account Settings bölümünde oluşturun; bir yıl geçerlidir. Hesap parolanız çalışmaz.

Değişiklikler otomatik olarak senkronize edilmez: düzenleyicide yapılan değişiklikleri almak için git pull, kendi değişikliklerinizi göndermek için git push kullanın. /git yolu sharelatex konteyneri tarafından sunulur; bu nedenle önündeki bir reverse proxy için ek bir kural gerekmez.

git push, HTTP 413 veya curl 55 Broken pipe hatasıyla başarısız oluyor

Push, yükleme boyutu sınırından büyüktür. Bu sınır MAX_UPLOAD_SIZE ile ayarlanır (megabayt cinsinden, varsayılan 50) ve push işlemleri için de geçerlidir. Bunu config/variables.env dosyasında artırın, örneğin MAX_UPLOAD_SIZE=200, ardından bin/up -d komutunu çalıştırın. TLS proxy veya kendi reverse proxy’nizi kullanıyorsanız, onun client_max_body_size değerini de artırın (Toolkit’in config/nginx/nginx.conf dosyasında 50M).

git-bridge ayrıca 50 MB’tan büyük dosyaları ve 2.000’den fazla dosya içeren projeleri reddeder. Bu sınırlar config/variables.env dosyasındaki GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE (bayt cinsinden) ve GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM ile ayarlanır.

git-bridge günlüğünde Failed to fetch log level görünüyor

Bu uyarı zararsızdır; klonlama, çekme ve gönderme çalışmaya devam eder. 6.2.x sürümünde git-bridge, dakikada bir Google Cloud meta veri sunucusundan (metadata.google.internal) bir günlük düzeyi ister; bu yalnızca Google Cloud üzerinde çalışır. Başka yerlerde istek başarısız olur, git-bridge hatayı (null veya bir HTTP durumu gibi) günlüğe yazar ve GIT_BRIDGE_LOG_LEVEL değerindeki düzeyi korur. 6.3.0 sürümünden itibaren bu denetim kapalıdır; yükseltme, sürümü ana imajı izleyen git-bridge imajını da günceller.

Git ve tam proje geçmişi için track-changes hizmetine veya OVERLEAF_IS_SERVER_PRO=true ayarına ihtiyacım var mı?

Yanıt: Hayır. Ayakaleaf Pro’da track-changes hizmeti yoktur. Proje geçmişi, her zaman sharelatex konteyneri içinde çalışan project-history ve history-v1 hizmetleri tarafından tutulur. git-bridge geçmişi, Toolkit’in ayarladığı V1_HISTORY_URL (http://sharelatex:3100/api) adresindeki history-v1 hizmetinden okur. OVERLEAF_IS_SERVER_PRO ayarlamayın: hiçbir özellik buna bağlı değildir; yalnızca başlangıçta çalıştırılan veritabanı geçişlerini Server Pro kümesine geçirir.