Puxar versão mais recente do git

Ainda não fez o deploy? → Faça o deploy de um site a partir de um repositório git ou Faça o deploy de um app web a partir de um repositório git

Depois que um site ou app é publicado a partir de um repositório git, enviar novos commits para o repositório não atualiza o servidor automaticamente. Clique em Puxar versão mais recente do git para deixar o servidor em dia — é só um clique, o Server Manager executa git pull --ff-only por trás dos panos e, no caso de apps web, instala novas dependências e reinicia seu app no systemd.

Quando o servidor está atrás do seu repositório, o cartão da carga de trabalho na tela inicial mostra um pequeno indicador **· ⤓ N behind** ao lado do status — num relance, você sabe que há algo para puxar. Passe o mouse por cima para ver o comando exato.

1. Abra o painel do serviço

Na tela inicial, clique no cartão do site ou app que você quer atualizar. O painel do serviço será aberto.

2. Abra a aba Controles e clique em "Puxar versão mais recente do git"

Tanto para sites estáticos quanto para apps web, Puxar versão mais recente do git fica na aba Controles, junto de Reiniciar / Parar / Iniciar / Gerar chave de deploy.

Por conveniência, o botão também aparece em mais dois lugares:

• Site estático — também na barra de ferramentas da aba Arquivos (⤓ Puxar versão mais recente do git), já que é onde usuários de sites estáticos costumam passar mais tempo.
• Qualquer tipo — na aba Status, quando há novos commits para puxar. Um banner "N commits atrás de origin" aparece com um botão Puxar versão mais recente ao lado. Use essa visualização quando quiser ver exatamente o que está pendente (quantidade de commits, SHA atual vs remoto) antes de puxar.

3. Faro faz o pull

O chat assume a partir daqui. Para um site estático, executamos git pull --ff-only e o Caddy continua servindo o site — não é preciso reiniciar. Para um app web, também instalamos novas dependências (npm ci / pip install) e reiniciamos o app.

4. Pronto

A seção de status do Git é atualizada para "Sincronizado" no novo commit.

Se o site não foi publicado a partir de um repositório git

Faro verifica isso primeiro e avisa no chat: "Este site não foi publicado a partir de um repositório git, então não há nada para puxar." Para substituir os arquivos, faça o deploy novamente com Faça o deploy de um site a partir do seu computador (ou o equivalente para app web) — solte uma pasta nova no mesmo site e nós substituímos o que está lá.

Se o pull falhar com "would be overwritten"

Usamos git pull --ff-only, que recusa merges que não sejam fast-forward. Se algo modificou um arquivo rastreado no servidor — a aba Arquivos, um cliente SFTP como FileZilla, uma sessão SSH ou até o próprio app em execução — o pull pode falhar com "Your local changes would be overwritten by merge".

A seção Status do Git na aba Status mostra o que mudou:

• M = um arquivo rastreado foi editado no servidor. Entra em conflito com o pull. Use o arquivo do repositório (descarta sua alteração local): execute sudo git checkout -- <file> a partir do caminho da carga de trabalho e tente puxar novamente.
• ? = um arquivo não rastreado (por exemplo, dados enviados por usuários em uploads/, arquivos de runtime que seu app cria). Não entra em conflito — git pull deixa arquivos não rastreados como estão. Nenhuma ação é necessária.

Para repositórios privados: gere uma chave de deploy primeiro

Na primeira vez que você usar Puxar versão mais recente em um repositório privado, a credencial HTTPS em cache não funcionará para pulls sem interação. A solução é criar uma chave de deploy uma única vez.

1. No painel do serviço, clique em Gerar chave de deploy (ao lado de Puxar versão mais recente).
2. Faro gera um par de chaves SSH no servidor e mostra a chave pública no chat.
3. Cole essa chave nas configurações do repositório → Deploy keys (GitHub) ou SSH keys (GitLab, Bitbucket, Codeberg, Gitea). NÃO marque acesso de escrita — acesso somente leitura é tudo de que precisamos.
4. Responda done no chat — Faro troca o remote do git de HTTPS para SSH e testa a conexão.

Depois disso, Puxar versão mais recente funciona sem pedir credenciais de novo.

Deploys em monorepo / subdiretório

Se você fez deploy a partir de um subdiretório de um monorepo (por exemplo, apps/web), Puxar versão mais recente continua funcionando — o sparse-checkout cuida disso por trás dos panos. Fazemos o pull para o clone de longa duração em /var/www/.helm-repos/<domain>/ (ou /opt/.helm-repos/<app>/ para um app web nativo), e seu diretório de deploy é um symlink que reflete automaticamente os novos arquivos.

Troca de branches

Puxar versão mais recente puxa da branch que você clonou durante o deploy inicial. Para trocar para outra branch, faça o deploy novamente pelo modal — escolha a nova branch em Avançado (git).