Uso de Dois Repositórios: Ambiente de Desenvolvimento (origin_dev) e Produção (origin)
Em projetos mais maduros — especialmente aqueles com maior criticidade, como sistemas embarcados industriais, firmware distribuído ou aplicações que exigem validação rigorosa — é comum evoluir além do modelo tradicional de um único repositório. A estratégia que você descreveu, utilizando dois repositórios distintos, um para desenvolvimento (origin_dev) e outro para produção (origin), é uma abordagem extremamente interessante, mas que exige disciplina e entendimento claro do fluxo.
Essa separação cria uma barreira explícita entre o que está sendo desenvolvido e o que está efetivamente liberado para uso. Em outras palavras, o repositório de desenvolvimento pode ser mais “flexível” e até desorganizado em certos momentos, enquanto o repositório de produção deve ser limpo, estável e altamente confiável.
Estrutura Geral da Estratégia
No seu modelo, o repositório origin_dev funciona como um ambiente de trabalho contínuo. Nele, os desenvolvedores enviam suas alterações livremente, normalmente sem a rigidez de um branch principal como main. Isso já é uma quebra de padrão em relação ao fluxo tradicional, mas faz sentido quando o objetivo é centralizar a evolução do código sem comprometer a estabilidade da versão final.
Já o repositório origin contém o branch main, que representa exclusivamente o código pronto para produção.
Para configurar esse ambiente localmente, você pode adicionar múltiplos remotes ao mesmo repositório Git:
git remote add origin_dev git@github.com:empresa/projeto-dev.git
git remote add origin git@github.com:empresa/projeto-prod.git
Para verificar os remotes configurados:
git remote -v
Isso permite que você trabalhe em um único diretório local, mas com dois destinos diferentes para envio de código.
Fluxo de Desenvolvimento no origin_dev
Os desenvolvedores trabalham normalmente no repositório de desenvolvimento, criando branches, realizando commits e enviando suas alterações:
git checkout -b feature/novo-modulo
git add .
git commit -m "Implementa novo módulo de comunicação (#58)"
git push origin_dev feature/novo-modulo
Nesse ambiente, o foco está na evolução do sistema. Como você mencionou, muitas vezes as informações adicionais são documentadas em arquivos como README.md, ROADMAP.md e TODO.md, o que ajuda a compensar uma possível falta de estrutura rígida.
No entanto, aqui cabe uma análise crítica importante: esse modelo pode facilmente virar “bagunça” se não houver um mínimo de governança. Commits mal descritos, branches sem padrão e falta de revisão podem dificultar muito a etapa seguinte, que é a consolidação da versão.
Criação do Branch de Versão
Quando chega o momento de preparar uma nova versão, entra uma etapa mais controlada do processo. A partir do código presente no origin_dev, você cria um branch de versão localmente:
git checkout -b release/v3.0.0
A partir desse ponto, começa um trabalho mais criterioso: você seleciona quais funcionalidades realmente farão parte da versão. Isso pode envolver merges seletivos:
git merge feature/novo-modulo
git merge feature/correcao-bug-critico
Nem tudo que está no origin_dev precisa entrar na versão. Esse processo funciona como uma “curadoria” do código.
É exatamente aqui que entra o ponto que você mencionou: “corrigir a bagunça”. Isso pode incluir:
- Resolver conflitos de merge
- Ajustar inconsistências de código
- Padronizar nomes e estruturas
- Remover trechos experimentais
- Garantir que tudo esteja funcionando de forma integrada
Essa etapa é trabalhosa, mas extremamente importante. Ela atua como um filtro entre desenvolvimento e produção.
Validação da Versão
Antes de promover o código para produção, o ideal é que esse branch de versão passe por testes:
- Testes funcionais
- Testes de integração
- Testes em hardware (no caso de firmware)
- Validação com cliente, quando aplicável
Durante esse processo, novos commits podem ser feitos diretamente no branch de versão:
git commit -m "Fix: corrige falha de sincronização no protocolo (#61)"
Se necessário, você também pode aplicar tags nesse ponto, marcando estados importantes da validação.
Promoção para Produção (origin)
Uma vez validado, o branch de versão é promovido para o repositório de produção. Primeiro, você garante que está atualizado:
git checkout main
git pull origin main
Em seguida, faz o merge da versão:
git merge release/v3.0.0
E então envia para o repositório de produção:
git push origin main
Esse momento representa oficialmente a liberação da nova versão.
Se quiser também publicar o branch de versão no repositório de produção (opcional):
git push origin release/v3.0.0
E, como boa prática, marcar a versão com uma tag:
git tag -a v3.0.0 -m "Versão 3.0.0 liberada"
git push origin v3.0.0
Sincronização entre Ambientes
Após a liberação, é importante manter os ambientes sincronizados. O origin_dev pode receber as alterações consolidadas do main, evitando divergências:
git checkout main
git pull origin main
git push origin_dev main
Isso garante que o ambiente de desenvolvimento não continue evoluindo sobre uma base desatualizada.
Análise Crítica da Estratégia
Essa abordagem é poderosa, mas não é trivial. Ela traz benefícios importantes:
- Isolamento entre desenvolvimento e produção
- Maior controle sobre o que entra em produção
- Possibilidade de consolidar versões com mais qualidade
Por outro lado, também apresenta desafios:
- Aumento da complexidade operacional
- Dependência de disciplina na equipe
- Maior esforço na fase de integração
Em muitos times, esse modelo pode ser substituído por alternativas como GitFlow ou Trunk-Based Development com pipelines de CI/CD. No entanto, em cenários onde o controle manual é necessário — como firmware embarcado com validação em hardware — essa estratégia continua extremamente válida.
