Servidor & DevOps 34 visualizações

Como automatizar deploys usando Git e um hook pós-recebimento (post-receive) no VPS

Ver no WHMCS

Como automatizar deploys usando Git e um hook post-receive no VPS

Olá! Aqui é a Sensei da GeHost 🥋. Hoje vamos falar de um truque clássico (e maravilhoso) do mundo DevOps: fazer o seu código ir do seu computador direto para o servidor com um simples git push — sem precisar subir arquivo por FTP, sem copiar pasta manualmente, sem estresse.

Isso é feito com um recurso do Git chamado hook post-receive. Vou te explicar com calma, passo a passo, para você conseguir configurar mesmo sem ser um especialista em servidores.

Este guia é voltado para ambientes de VPS com acesso SSH (ou seja, um servidor onde você tem acesso via terminal e pode instalar/configurar o Git livremente). Se você não sabe qual é o tipo do seu ambiente de hospedagem, dá uma olhada no painel.gehost.com.br ou fale com nosso suporte antes de seguir — cada tipo de plano tem suas particularidades.

O que é um hook post-receive?

Pense no Git como um carteiro. Quando você dá um git push, ele entrega os seus arquivos até o repositório do servidor. Um hook é um "script de recado" que o Git executa automaticamente assim que essa entrega termina.

O post-receive é o hook que roda depois que o servidor recebeu tudo. É o momento perfeito para dizer: "ok, chegou código novo, agora copie ele para a pasta do site (ou reinicie a aplicação)".

Resultado: você digita um comando no seu computador e, em segundos, seu site/aplicação já está atualizado no servidor. Isso é o que chamamos de deploy automatizado.

Antes de começar: o que você precisa

  • Acesso SSH ao seu VPS (usuário e chave/senha configurados);
  • Git instalado no servidor (a maioria dos VPS já vem com ele; se não tiver, seu provedor de sistema operacional deve orientar a instalação);
  • Um projeto versionado com Git no seu computador local.

Passo a passo

1. Criar o repositório "bare" no servidor

No servidor, você vai criar uma pasta especial chamada repositório bare — é um repositório Git que não guarda os arquivos "visíveis", só o histórico. Ele serve como o ponto de chegada dos seus pushes.

Conecte no servidor via SSH e rode:

  1. Crie uma pasta para o repositório, por exemplo: mkdir -p ~/meu-projeto.git
  2. Entre nela: cd ~/meu-projeto.git
  3. Inicialize como bare: git init --bare
Dica da Sensei: use um nome terminado em .git para deixar claro que essa pasta é só o "repositório de recebimento", diferente da pasta onde o site realmente vai morar.

2. Definir a pasta de destino (onde o site vai ficar)

Agora escolha (ou crie) a pasta onde os arquivos do seu projeto/site vão ficar "vivos" de verdade — é para lá que o hook vai copiar o código depois de cada push. Por exemplo: ~/apps/meu-projeto.

3. Criar o script do hook post-receive

Dentro do repositório bare que você criou, existe uma subpasta chamada hooks. É lá que a mágica acontece. Vamos criar o arquivo:

  1. Entre na pasta de hooks: cd ~/meu-projeto.git/hooks
  2. Crie o arquivo do hook: nano post-receive (ou use o editor de texto de sua preferência)
  3. Cole um script parecido com este:

#!/bin/bash
GIT_WORK_TREE=/caminho/para/apps/meu-projeto git checkout -f

Esse comandinho simples diz ao Git: "sempre que receber um push, pegue os arquivos mais recentes e coloque-os na pasta de destino". Se o seu projeto precisar de passos extras depois do checkout (como instalar dependências ou reiniciar um serviço), você pode incluir esses comandos nas linhas seguintes do mesmo script.

4. Dar permissão de execução ao hook

Um hook só funciona se o sistema souber que ele pode ser executado. Ainda dentro da pasta hooks, rode:

chmod +x post-receive

Pronto — sem esse passo, o Git simplesmente ignora o arquivo, então não pule esta parte!

5. Adicionar o servidor como "remote" no seu projeto local

Agora, no seu computador (não no servidor), dentro da pasta do seu projeto local, rode:

git remote add producao usuario@seu-servidor:~/meu-projeto.git

Você pode trocar o nome producao pelo que preferir — é só um apelido para esse destino de deploy.

6. Testar o deploy

Chegou a hora da verdade! Faça um commit qualquer e envie:

git push producao main

(troque main pelo nome da sua branch principal, se for diferente). Se tudo estiver certo, você verá o Git enviando os arquivos e, na sequência, os arquivos vão aparecer atualizados na pasta de destino no servidor. 🎉

Boas práticas e cuidados

  • Nunca dê push direto na pasta onde o site "vive": sempre use um repositório bare separado como ponto de recebimento, como fizemos acima. Isso evita conflitos e arquivos corrompidos.
  • Teste em um ambiente de homologação primeiro se o seu projeto for crítico, antes de automatizar o deploy direto em produção.
  • Faça backup antes de mexer em scripts de automação. Se o seu plano incluir rotina de backup, você pode conferir as opções disponíveis no seu painel.
  • Cuidado com arquivos sensíveis (senhas, chaves de API): nunca deixe esse tipo de dado dentro do repositório Git. Prefira variáveis de ambiente configuradas diretamente no servidor.
Dica da Sensei: comece simples! Primeiro deixe o hook funcionando só com o checkout dos arquivos. Depois que estiver confiante, vá adicionando automações extras (como reiniciar serviços ou rodar builds) uma de cada vez.

Precisa de ajuda?

Se você tiver qualquer dúvida durante a configuração, nossa equipe de suporte está pronta para te orientar. Você também pode acompanhar detalhes do seu plano e ambiente pelo painel.gehost.com.br.

Até a próxima aula, e bons deploys! 🚀

Precisa de Ajuda?

Nossa equipe está pronta para resolver suas dúvidas.