Git 連携

ユーザーが git-bridge を通じて Git でプロジェクトを clone、pull、push できるようにします。

Git 連携は現在、ayaka-notes/overleaf で利用できます。

この機能は当初 ayaka-notes/ayakaleaf-pro によって開発されました。

1. git-bridge を有効にする（Toolkit ユーザーのみ）

   Toolkit を使用している場合は、config/overleaf.rc で次のように設定して git-bridge を有効にします。

   config/overleaf.rc

   GIT_BRIDGE_ENABLED=true
   

   SERVER_PRO=true も設定されていない限り、Toolkit はこの設定を無視します。他に必要な設定はありません。Toolkit が sharelatex コンテナ用の GIT_BRIDGE_HOST、GIT_BRIDGE_PORT、V1_HISTORY_URL を自動で設定するため、以下の 2 つの Docker Compose 用の手順はスキップしてください。bin/up を実行してコンテナを再作成します。

2. git-bridge コンテナを追加する（Docker-compose ユーザーのみ）

   独自の docker-compose.yml を実行しているユーザーは、compose ファイルに次のコンテナ設定を追加してください。

   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 イメージと同じタグを使用してください。MCP サーバー(v6.3.1 以降)は sharelatex イメージに含まれており、Git 連携と一緒に有効になるため、追加のコンテナは不要です。

3. sharelatex コンテナの設定を更新する

   また、sharelatex コンテナで git-bridge コンテナをリンクし、次の環境変数を定義する必要があります。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. 認証

   git クライアントを認証する際、ユーザーにはパーソナルアクセストークンが必要です。ユーザーはアプリケーションの UI からパーソナルアクセストークンを管理できます（ドキュメントを参照してください）。

   

   Git 連携のパーソナルアクセストークン

5. 監視とリソースに関する考慮事項

   git-bridge を有効にした後は、ホストのリソースを監視することをおすすめします。負荷の増加は次の要素によって異なります。

   • この機能にアクセスするユーザー数
   • インスタンスでホストされているプロジェクトの種類（一般に、大きなプロジェクトほど多くのリソースを消費します）

​

プロジェクトを S3 にスワップする

Git 連携では、ユーザーがクローンしたプロジェクトごとに完全な git リポジトリがディスク上に保存されます。ディスク容量が限られている場合は、あまり使用されていないリポジトリを AWS S3 に移動するスワップジョブを有効にできます。スワップされたリポジトリが再び必要になると、ディスクに戻されます。スワップジョブは次の環境変数で制御します。

名前	説明
GIT_BRIDGE_SWAPSTORE_TYPE	スワップジョブを有効にするには “s3” に設定します。
GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY	AWS のアクセスキー
GIT_BRIDGE_SWAPSTORE_AWS_SECRET	AWS のシークレット
GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME	圧縮された git リポジトリを格納するバケット
GIT_BRIDGE_SWAPSTORE_AWS_REGION	バケットのリージョン
GIT_BRIDGE_SWAPJOB_MIN_PROJECTS	ディスク上に最低限保持するプロジェクト数。 - デフォルト： 50
GIT_BRIDGE_SWAPJOB_LOW_GIB	スワップの下限しきい値。スワップジョブはディスク使用量がこの値を下回るまでプロジェクトを移動します。 - デフォルト： 128 GB
GIT_BRIDGE_SWAPJOB_HIGH_GIB	スワップの上限しきい値。ディスク使用量がこの値に達するとスワップジョブがスワップを開始します。 - デフォルト： 256 GB
GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS	ディスク使用量の確認とスワップジョブの実行の間隔。 - デフォルト： 3600000 ms = 1 時間

​

Q&A

プロジェクトを他の人と共有した場合、Git Bridge の権限モデルはどのように機能しますか？

読み取り専用アクセス権を持つユーザーはこのプロジェクトをクローンすることしかできません。読み書きアクセス権を持つユーザーはプロジェクトをクローンおよびプッシュできます。注：このプロジェクトに参加するには、ユーザーがログインしている必要があります。

プロジェクトをクローンするにはどうすればよいですか？また、どのユーザー名とパスワードを使用しますか？

エディターで、左レールの Integrations を開き、Git integration をクリックします。次の形式でクローンコマンドが表示されます。

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

Git から認証情報を求められたら、ユーザー名に git、パスワードに Personal Access Token を入力します。トークンは Account Settings で生成でき、有効期間は 1 年です。アカウントのパスワードは使用できません。

変更は自動的には同期されません。エディターで行われた変更を取得するには git pull を、自分の変更を送信するには git push を使用します。/git パスは sharelatex コンテナによって提供されるため、その前段のリバースプロキシに追加のルールは必要ありません。

git push が HTTP 413 または curl 55 Broken pipe で失敗する

プッシュがアップロードサイズの上限を超えています。この上限は MAX_UPLOAD_SIZE(メガバイト単位、デフォルトは 50)で設定され、プッシュにも適用されます。config/variables.env で、たとえば MAX_UPLOAD_SIZE=200 のように引き上げてから、bin/up -d を実行してください。TLS プロキシまたは独自のリバースプロキシを使用している場合は、その client_max_body_size(Toolkit の config/nginx/nginx.conf では 50M)も引き上げてください。

git-bridge は、50 MB を超えるファイルや 2,000 を超えるファイルを含むプロジェクトも拒否します。これらの上限は、config/variables.env の GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE(バイト単位)と GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM で設定されます。

git-bridge のログに Failed to fetch log level と表示される

この警告は無害で、clone、pull、push は引き続き動作します。6.2.x では、git-bridge が 1 分に 1 回 Google Cloud のメタデータサーバー(metadata.google.internal)にログレベルを問い合わせますが、これは Google Cloud 上でのみ機能します。それ以外の環境ではリクエストが失敗し、git-bridge はエラー(null や HTTP ステータスなど)をログに記録して、GIT_BRIDGE_LOG_LEVEL のレベルを維持します。6.3.0 以降ではこのチェックは無効になっています。また、アップグレードすると git-bridge イメージも更新されます。このイメージのバージョンはメインイメージに追従します。

Git や完全なプロジェクト履歴のために、track-changes サービスや OVERLEAF_IS_SERVER_PRO=true は必要ですか？

回答：いいえ。Ayakaleaf Pro には track-changes サービスはありません。プロジェクト履歴は project-history サービスと history-v1 サービスによって保持され、これらは常に sharelatex コンテナ内で実行されます。git-bridge は V1_HISTORY_URL(http://sharelatex:3100/api)の history-v1 から履歴を読み取ります。この値は Toolkit が設定します。OVERLEAF_IS_SERVER_PRO は設定しないでください。これに依存する機能はなく、起動時に実行されるデータベースマイグレーションを Server Pro 用のものに切り替えるだけです。