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

# Integração com Git

> Permita que os usuários clonem, façam pull e push dos seus projetos com Git por meio do git-bridge.

A integração com Git está disponível atualmente em [ayaka-notes/overleaf](https://github.com/ayaka-notes/overleaf).

> [!NOTE]
>
> Este recurso foi desenvolvido inicialmente por [ayaka-notes/ayakaleaf-pro](https://github.com/ayaka-notes/ayakaleaf-pro).

**1. Ativar o git-bridge (apenas para usuários do Toolkit)**

Se você estiver usando o Toolkit, ative o `git-bridge` definindo o seguinte em seu `config/overleaf.rc`:

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

O Toolkit a ignora, a menos que `SERVER_PRO=true` também esteja definida. Nada mais é necessário: o próprio Toolkit define `GIT_BRIDGE_HOST`, `GIT_BRIDGE_PORT` e `V1_HISTORY_URL` para o contêiner `sharelatex`, então pule as duas etapas do Docker Compose abaixo. Execute `bin/up` para recriar os contêineres.

**2. Adicionar o contêiner git-bridge (apenas para usuários do Docker-compose)**

Para usuários que executam um `docker-compose.yml` personalizado, adicione a seguinte configuração de contêiner ao seu arquivo compose:

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

Use a mesma tag da imagem `sharelatex`. O [MCP Server](https://ayakaleaf-pro.mintlify.site/pt/on-premises/configuration/overleaf-toolkit/integrations/mcp-server.md) (v6.3.1 e posteriores) faz parte da imagem `sharelatex` e é habilitado junto com a integração com Git, então não precisa de nenhum contêiner extra.

**3. Atualizar a configuração do contêiner sharelatex**

Você também precisará vincular o contêiner `git-bridge` ao contêiner `sharelatex` e definir as seguintes variáveis de ambiente; preste atenção a `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. Autenticação**

Ao autenticar um cliente git, os usuários precisam de um Personal Access Token. Os usuários podem gerenciar Personal Access Tokens pela interface da aplicação (consulte a documentação):

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

Personal Access Token da integração com Git

**5. Monitoramento e considerações sobre recursos**

Recomendamos monitorar os recursos do seu host depois de ativar o `git-bridge`. O aumento de carga dependerá de:

* o número de usuários que acessam o recurso
* os tipos de projetos hospedados na sua instância (projetos maiores geralmente consomem mais recursos)

### Transferência (swap) de projetos para o S3

A integração com Git armazena em disco um repositório git completo para cada projeto clonado por um usuário. Se você tiver espaço em disco limitado, pode ativar um job de swap que moverá os repositórios menos usados para o AWS S3. Se um repositório transferido for necessário novamente, ele será movido de volta para o disco. As seguintes variáveis de ambiente controlam o job de swap:

| Nome | Descrição |
| - | - |
| `GIT_BRIDGE_SWAPSTORE_TYPE` | Defina como "s3" para ativar o job de swap. |
| `GIT_BRIDGE_SWAPSTORE_AWS_ACCESS_KEY` | Sua chave de acesso da AWS |
| `GIT_BRIDGE_SWAPSTORE_AWS_SECRET` | Seu segredo da AWS |
| `GIT_BRIDGE_SWAPSTORE_S3_BUCKET_NAME` | Este bucket conterá os repositórios git compactados |
| `GIT_BRIDGE_SWAPSTORE_AWS_REGION` | A região do bucket |
| `GIT_BRIDGE_SWAPJOB_MIN_PROJECTS` | Quantos projetos manter em disco, no mínimo. **- Padrão:** 50 |
| `GIT_BRIDGE_SWAPJOB_LOW_GIB` | Limite inferior para o swap. O job de swap moverá projetos até que o uso do disco fique abaixo desse valor. **- Padrão:** 128 GB |
| `GIT_BRIDGE_SWAPJOB_HIGH_GIB` | Limite superior para o swap. O job de swap começará a transferir quando o uso do disco atingir esse valor. **- Padrão:** 256 GB |
| `GIT_BRIDGE_SWAPJOB_INTERVAL_MILLIS` | O intervalo de tempo entre as verificações de uso do disco e a execução do job de swap. **- Padrão:** 3600000 ms = 1 hora |

### Perguntas e respostas

> [accordion] Se eu compartilhar meu projeto com outra pessoa, como funciona o modelo de permissões do Git Bridge?
>
> Usuários com acesso somente leitura podem apenas clonar este projeto; usuários com acesso de leitura e gravação podem clonar e fazer push nos projetos. Observação: os usuários precisam estar logados para participar deste projeto.

> [accordion] Como clonar um projeto e qual nome de usuário e senha devo usar?
>
> No editor, abra **Integrations** na barra lateral esquerda e clique em **Git integration**. Ali é exibido o comando de clonagem, no formato:
>
> ```sh theme={null}
> git clone https://<your-overleaf>/git/<project_id>
> ```
>
> Quando o Git pedir credenciais, informe `git` como nome de usuário e um Personal Access Token como senha. Gere o token em **Account Settings**; ele é válido por um ano. A senha da sua conta não funciona.
>
> As alterações não são sincronizadas automaticamente: use `git pull` para obter as alterações feitas no editor e `git push` para enviar as suas. O caminho `/git` é servido pelo contêiner `sharelatex`, então um proxy reverso na frente dele não precisa de nenhuma regra extra.

> [accordion] `git push` falha com `HTTP 413` ou `curl 55 Broken pipe`
>
> O push é maior que o limite de tamanho de upload, definido por `MAX_UPLOAD_SIZE` (em megabytes, `50` por padrão), que também se aplica a pushes. Aumente-o em `config/variables.env`, por exemplo `MAX_UPLOAD_SIZE=200`, e depois execute `bin/up -d`. Se você usa o [proxy TLS](https://ayakaleaf-pro.mintlify.site/pt/on-premises/configuration/overleaf-toolkit/tls-proxy.md) ou seu próprio proxy reverso, aumente também o `client_max_body_size` dele (`50M` no `config/nginx/nginx.conf` do Toolkit).
>
> O git-bridge também recusa arquivos maiores que 50 MB e projetos com mais de 2.000 arquivos. Esses limites são definidos por `GIT_BRIDGE_REPOSTORE_MAX_FILE_SIZE` (em bytes) e `GIT_BRIDGE_REPOSTORE_MAX_FILE_NUM` em `config/variables.env`.

> [accordion] O log do git-bridge mostra `Failed to fetch log level`
>
> O aviso é inofensivo, e clone, pull e push continuam funcionando. Na versão 6.2.x, o git-bridge consulta o servidor de metadados do Google Cloud (`metadata.google.internal`) uma vez por minuto para obter um nível de log, o que só funciona no Google Cloud. Em outros ambientes, a solicitação falha, o git-bridge registra o erro (como `null` ou um status HTTP) e mantém o nível definido em `GIT_BRIDGE_LOG_LEVEL`. A partir da 6.3.0, essa verificação está desativada, e a atualização também atualiza a imagem do git-bridge, cuja versão acompanha a imagem principal.

> [accordion] Preciso do serviço track-changes ou de `OVERLEAF_IS_SERVER_PRO=true` para o Git e o histórico completo do projeto?
>
> **Resposta:** Não. O Ayakaleaf Pro não tem um serviço track-changes. O histórico do projeto é mantido pelos serviços `project-history` e `history-v1`, que sempre são executados dentro do contêiner `sharelatex`. O git-bridge lê o histórico do `history-v1` em `V1_HISTORY_URL` (`http://sharelatex:3100/api`), que o Toolkit define. Não defina `OVERLEAF_IS_SERVER_PRO`: nenhum recurso depende dela; ela apenas faz com que as migrações de banco de dados executadas na inicialização passem a ser as do conjunto do Server Pro.


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