Quais ramas você realmente precisa em um projeto real

Publicado em 2026-09-12 por frfrand

Los flujos de trabajo famosos resuelven problemas que quizá no tenés. Tres modelos, para qué sirve cada uno, y cómo elegir según cómo publicás y cuántos son.

Quando alguém busca "como organizar os ramos", encontra diagramas complexos com cinco tipos distintos. A maioria foi pensada para um contexto específico que talvez não seja o seu.

Antes de escolher um modelo, convém responder a uma pergunta: como você publica?

Modelo 1: um único ramo

Todo mundo trabalha sobre main. Os ramos existem, mas duram horas ou um dia, e são integrados imediatamente.

Funciona muito bem quando você publica com frequência e tem testes em que confia. É o que a maioria das equipes que implantam várias vezes por dia usa.

O que requer para não ser um desastre:

• Testes automáticos que rodem em cada integração e em que você realmente confie.
• Interruptores de funcionalidade: se algo não estiver pronto, é integrado desligado em vez de ficar em um ramo.

Isso último é o que mais custa adotar e o que torna o modelo viável. Permite integrar código incompleto sem que chegue aos usuários.

Modelo 2: dois ramos

Um ramo de integração (main) e um de produção.

• main recebe tudo o que vai ficando pronto, e é implantado apenas no staging.
• Quando se quer publicar, integra-se main no ramo de produção, e isso dispara a implantação no site real.

Publicar é um merge. Voltar atrás é um revert. Qualquer pessoa da equipe entende o estado do sistema olhando dois ramos.

Para uma equipe de duas a dez pessoas que publica algumas vezes por semana, este modelo é difícil de superar pela relação entre simplicidade e controle. É o que usamos.

Modelo 3: Git flow

O famoso, com ramais de desenvolvimento, de funcionalidade, de release, de hotfix e master.

Foi projetado em 2010 para software com versões: um programa que se baixa, onde convivem a 2.3 e a 2.4, e é preciso poder corrigir uma versão antiga sem incluir o novo.

Se esse é o seu caso (uma biblioteca, um aplicativo de desktop, algo instalado em clientes), o Git flow resolve problemas reais.

Se você tem um aplicativo web onde a única versão que existe é a que está rodando, o Git flow adiciona cerimônia sem resolver nada. O próprio autor publicou anos depois uma nota dizendo exatamente isso.

Como escolher, em uma pergunta

Precisa manter versões antigas em paralelo?

• Sim → Git flow ou algo parecido.
• Não, e você publica várias vezes por dia → uma única ramificação com interruptores.
• Não, e você publica algumas vezes por semana → duas ramificações.

Detalhes que importam mais que o modelo

Nomes com prefixo. feature/, fix/, chore/. Permite filtrar e entender de um olhar. E se você incluir o número do ticket, a rastreabilidade sai de graça.

Excluir as ramificações integradas. Um repositório com oitenta ramificações antigas é puro ruído. A maioria das plataformas faz isso sozinha ao fechar um pull request.

Proteger a ramificação de produção. Sem push direto, com revisão obrigatória. Não por desconfiança: porque às sete da noite qualquer um erra de ramificação.

Ramos curtos. Isso importa mais do que tudo o anterior junto. Um modelo mal escolhido com ramos de dois dias funciona bem. O melhor modelo do mundo com ramos de um mês, não.

No ArduMaker cada implantação se associa a um ramo, assim você pode ter o mesmo repositório publicado duas vezes no mesmo VPS: uma de main para staging e outra de produccion para o domínio real.