Branches, fluxo de trabalho e Git de gente grande

💡 TL;DR (Resumo)

Git branches são fundamentais para times. Escolha uma estratégia (Git Flow ou Trunk-Based), mantenha main sempre deployável, use branches de vida curta para features, faça PRs pequenos e focados, entenda merge vs rebase, e estabeleça acordos simples com o time. A diferença entre um dev caótico e um profissional é exatamente isso: organização de fluxo.

Se o seu uso de Git se resume a git add ., git commit e git push direto na main, você está jogando no modo fácil e deixando produtividade (e sanidade) na mesa.

Neste artigo vamos sair do Git "solo" e entrar no Git para times:

Como usar branches de forma inteligente
Estratégias de branching (sem religião)
Merge vs rebase na prática
Como não virar o dev que quebra a main toda semana
Dicas reais para PRs (pull requests) que o time agradece

1. Por que branches importam tanto assim?

Branches são a base de qualquer fluxo de trabalho minimamente decente em Git.

Sem branch:

Tudo cai na main
Bug em teste derruba código estável
Fica difícil saber o que entrou quando

Com branch bem usada:

Você isola features, bugfixes e hotfixes
Consegue revisar código por pedaço (pull requests)
Facilita rollback de funcionalidades específicas

Regra de ouro: main (ou master) deve estar sempre em estado deployável.

Se não dá pra fazer deploy da main a qualquer momento, seu fluxo está te sabotando.

2. Criando e navegando entre branches

Vamos recapitular e organizar as principais operações com branches.

Criar uma nova branch a partir da atual

bash

git checkout -b feature/tela-login

Isso é equivalente a:

bash

git branch feature/tela-login
git checkout feature/tela-login

Ver todas as branches

bash

git branch        # locais

git branch -a     # locais + remotas

Trocar de branch

bash

git checkout main

Se quiser trocar e já criar caso não exista (Git mais novo):

bash

git switch -c feature/tela-perfil   # cria e vai pra branch

git switch main                      # só troca

3. Estratégias de branching sem fanatismo

Existem vários modelos famosos. Vamos falar dos dois mais usados na prática.

3.1. Git Flow (clássico)

Útil em times com ciclos de release mais definidos.

Branches principais:

main → produção
develop → integração contínua de features

Branches de suporte:

feature/* → novas funcionalidades
release/* → estabilizar uma versão antes de ir pra produção
hotfix/* → correções emergenciais em produção

Pontos positivos:

Bem organizado pra releases "versão 1.2.3"
Bom pra produtos com versões fechadas

Pontos negativos:

Pode ser burocrático demais pra times menores
Muita branch pra pouca gente

3.2. Trunk-Based Development (TBD)

Mais moderno e comum em times que fazem deploy frequente.

main (ou trunk) é a branch central
Features vivem em branches curtas, que voltam rápido pra main
Feature flags (flags de recurso) controlam funcionalidades inacabadas

Pontos positivos:

Menos branch "perdida"
Facilita entrega contínua

Pontos negativos:

Requer disciplina forte de testes e automação
Se mal feito, vira festa na main

Resumo honesto: escolha UM modelo, adapte, documente e faça todo mundo seguir. Modelo sem consenso vira caos versionado.

4. O ciclo saudável de uma feature

Um fluxo saudável pra uma nova feature poderia ser:

Atualizar sua main local

bash

git checkout main
git pull origin main

Criar uma branch de feature

bash

git checkout -b feature/tela-login

Fazer pequenos commits com mensagens decentes

bash

git add .
git commit -m "feat: adiciona layout básico da tela de login"

# ...

git commit -m "feat: integra tela de login com API de autenticação"

Atualizar sua branch em relação à main

Opção segura (merge):

bash

git checkout feature/tela-login
git fetch origin
git merge origin/main

Opção com histórico mais limpo (rebase):

bash

git checkout feature/tela-login
git fetch origin
git rebase origin/main

Abrir um Pull Request (PR) da sua branch para main ou develop
Após review, mergear e deletar a branch de feature

bash

git checkout main
git pull origin main  # pega o merge

git branch -d feature/tela-login            # local

git push origin --delete feature/tela-login # remoto (se quiser limpar)

5. Merge na prática: quando e como usar

O comando básico:

bash

git checkout main
git pull origin main

git merge feature/tela-login

Se não houver conflitos, o Git cria um novo commit de merge.

Merge commit vs fast-forward

Fast-forward: quando a main não andou desde que você criou a branch. O Git "avança o ponteiro" sem criar commit de merge.
Merge commit: quando a main também teve mudanças. O Git cria um commit extra com dois pais.

Você pode controlar isso com flags:

bash

git merge --no-ff feature/tela-login   # sempre cria commit de merge

git merge --ff-only feature/tela-login # só faz fast-forward, senão falha

Time que gosta de ver PRs muito bem marcados geralmente usa --no-ff para preservar o "bloco" da feature.

6. Rebase: deixando o histórico linear (e bonito)

git rebase reescreve a base dos seus commits como se tivessem sido criados sobre outro ponto.

Fluxo comum:

bash

git checkout feature/tela-login
git fetch origin
git rebase origin/main

Se houver conflito:

Edite os arquivos conflitantes
git add nos arquivos resolvidos
Continue o rebase:

bash

git rebase --continue

Se der ruim e você quiser desistir:

bash

git rebase --abort

Regra de sobrevivência: reescrever histórico público é pedir caos. Rebase é excelente em branch local, perigoso em branch compartilhada.

7. Pull requests que o time AMA (e aprova rápido)

Pull request não é só clicar no botão.

Dicas práticas:

Faça PRs pequenos e focados (ideal: 100–300 linhas, não 3000)
Escreva descrição decente: o que foi feito, por quê, como testar
Marque pessoas certas pra review (não o time inteiro à toa)
Use rótulos (labels) pra categorizar (bug, feature, hotfix)

Exemplo de descrição:

text

## O que foi feito
- Adiciona tela de login com email/senha
- Integra com API /auth/login

## Como testar
1. Rodar `npm install && npm start`
2. Acessar /login
3. Tentar login com usuário válido

## Observações
- Ainda não há fluxo de "esqueci minha senha"

Quanto mais claro, mais fácil a aprovação.

8. Lidando com conflitos sem entrar em pânico

Conflito de merge ou rebase não é sinal de fracasso, é sinal de que o time está trabalhando em paralelo.

Quando o Git avisar que há conflito:

Veja quais arquivos estão em conflito

bash

git status

Abra o arquivo: você verá algo como:

text

<<<<<<< HEAD
código da sua branch atual
=======
código da outra branch
>>>>>>> feature/alguma-coisa

Edite o arquivo mantendo o que fizer sentido (às vezes os dois lados), e remova os marcadores <<<<<<<, =======, >>>>>>>.
Marque como resolvido e continue:

bash

git add caminho/do/arquivo
# se for merge normal
git commit

# se for rebase
git rebase --continue

Dica: ferramentas como VS Code, IntelliJ, etc. ajudam MUITO a visualizar conflitos, mas entenda o que está acontecendo por baixo.

9. Pequenos acordos de time que evitam grandes tretas

Algumas combinações simples:

"Nunca damos push --force na main"
"Sempre atualizamos a branch a partir da main antes de abrir PR"
"PR precisa de pelo menos 1 ou 2 aprovações"
"Não fazemos merge vermelho (build quebrado)"
"Branches de feature duram dias, não meses"

Esses acordos parecem burocracia, mas salvam de muito retrabalho.

10. Resumo: Git de gente grande é mais sobre TIME do que sobre COMANDO

Neste artigo, você viu:

Por que branches são essenciais num time real
Diferentes estratégias (Git Flow vs Trunk-Based)
Merge e rebase aplicados ao dia a dia
Como montar um ciclo saudável de feature
Como escrever PRs que facilitam a vida de todo mundo

Dominar isso muda como o time te enxerga:

Você passa de "quem sabe rodar git" pra "quem organiza o fluxo".

No próximo artigo, vamos aprofundar em comandos poderosos e menos óbvios:

revert, cherry-pick, reflog, bisect
E mais táticas pra investigar bugs e recuperar trabalho.

Branches, fluxo de trabalho e Git de gente grande

✨TL;DR / Sumário Executivo

💡 TL;DR (Resumo)

1. Por que branches importam tanto assim?

2. Criando e navegando entre branches

Criar uma nova branch a partir da atual

Ver todas as branches

Trocar de branch

3. Estratégias de branching sem fanatismo

3.1. Git Flow (clássico)

3.2. Trunk-Based Development (TBD)

4. O ciclo saudável de uma feature

5. Merge na prática: quando e como usar

Merge commit vs fast-forward

6. Rebase: deixando o histórico linear (e bonito)

7. Pull requests que o time AMA (e aprova rápido)

8. Lidando com conflitos sem entrar em pânico

9. Pequenos acordos de time que evitam grandes tretas

10. Resumo: Git de gente grande é mais sobre TIME do que sobre COMANDO

Receba novos artigos