Nem Todo Branch é Igual
Assim que o time passou de três pessoas, nosso histórico Git virou bagunça. Merge conflict. Branch parado. Experimento esquecido. Main quebrado.
Não era falta de habilidade. Era falta de estrutura. Cada um com seu estilo. Alguns commitavam direto na main. Outros criavam branch pra tudo—mas nunca limpavam depois. O que faltava era estratégia, não boa vontade.
Foi aí que mergulhei nos workflows do Git. Não só comandos, mas estruturas de trabalho em equipe. GitFlow, GitHub Flow, trunk-based development—não eram buzzwords. Eram ferramentas de sobrevivência.
Com tempo e erro, aprendi o mais importante: propósito. Um branch com motivo claro é mais fácil de trabalhar, revisar e deletar.
O Papel dos Branches em Times
Branch é uma fronteira. Um espaço seguro pra trabalhar sem atrapalhar o outro. Mas essa fronteira precisa estar bem definida.
O que mais fez diferença pra gente:
- Convenção de nomes (ex:
feature/user-profile,bugfix/login-error) - Branches de vida curta (merge em dias, não semanas)
- Ligados a tarefas (tickets, objetivos claros)
- Deletados após merge
| Prática | Benefício |
|---|---|
| Nome claro no branch | Facilita comunicação e rastreamento |
| Vida curta | Menos conflitos, feedback mais rápido |
| Deletar após merge | Evita bagunça, reduz confusão |
Adotamos uma versão leve do GitHub Flow:
- Começa da
main - Cria uma branch por feature
- Abre PR logo no início
- Commits limpos e focados
- Merge com rebase ou squash
Não resolveu tudo. Mas criou um ritmo compartilhado.
Escalando com Confiança e Simplicidade
Com o crescimento, o processo quebrou. O que funcionava pra 5 devs não servia pra 15. Então simplificamos.
Alguns times migraram pro trunk-based development:
- Todo mundo commita direto na
main, atrás de feature flags - Branches minúsculos (às vezes um commit só)
- CI controlando tudo
Assustou no começo. Mas forçou testes melhores, ownership mais claro e integração contínua.
| Estilo de Workflow | Melhor Para |
|---|---|
| GitHub Flow | Times assíncronos, tamanho médio |
| Trunk-based development | Alta colaboração, ritmo intenso |
| GitFlow (legado) | Fluxos complexos de release |
Não existe solução mágica. Mas existe um sinal de alerta: branch que vive demais é sinal de confiança de menos. Branch longo geralmente indica trabalho estagnado, insegurança ou meta mal definida.
Mantenha branches curtos. Com objetivo claro. E delete sem apego.
Branch Também Conta História
A gente pensa nos commits como história. Mas branches também contam. Mostram como o trabalho andou, quem fez, quando ficou pronto.
Um branch com nome bom e vida curta diz: “sei o que estou fazendo e já volto.” Um branch esquecido diz o oposto.
Não precisa regra complicada. Precisa intenção constante. Use branches pra isolar, alinhar e entregar.
Crie branches com propósito. O time vai junto.