Git, GitHub e GitLab, estratégias de branching e revisão de código

Do zero

O Git é distribuído: cada pessoa da equipe tem uma cópia inteira do projeto, com todo o histórico, no próprio computador. É como se cada um tivesse o livro completo da obra, e não só a página em que está trabalhando. Dá para registrar e consultar o histórico sem internet; o servidor (GitHub, GitLab) é o ponto de encontro onde as cópias se sincronizam.

Quando várias pessoas mexem no mesmo código, é preciso combinar como os trabalhos se juntam. Isso é a estratégia de branching. Pense numa estrada:

• No Git Flow, há várias pistas fixas: uma para o que está em produção (main), outra para o que está sendo integrado (develop) e saídas temporárias para cada funcionalidade, versão ou correção urgente.
• No trunk-based development (desenvolvimento no tronco), há uma pista principal só. Cada um sai dela por pouco tempo (horas ou um dia), volta logo e junta o trabalho ao tronco várias vezes por dia.

E antes de juntar o trabalho ao principal, alguém confere: é o pull request (no GitHub) ou merge request (no GitLab), um pedido formal de “por favor, revise e junte”. Nele, os colegas comentam, os testes automáticos rodam e só então o código entra.

Frase para guardar: Git é distribuído; Git Flow tem branches fixos para versões, trunk-based integra no tronco todo dia; pull request é o pedido de revisão antes do merge.

Em 1 minuto

• GitHub e GitLab hospedam repositórios e somam colaboração: issues, pull requests ou merge requests, revisão de código, wikis e automação (GitHub Actions, GitLab CI/CD).
• Git Flow: main (só versões publicadas, com tag), develop (integração), feature/* (saem de develop e voltam a ele), release/* (preparam a versão; vão para main e develop) e hotfix/* (saem de main para uma correção urgente; voltam a main e develop; se houver um release em andamento, vão para ele em vez do develop). Bom para software com versões numeradas e ciclos de entrega definidos.
• GitHub Flow: só main e branches curtos por mudança, sempre com pull request; o que está na main pode ir para produção.
• Trunk-based: todos integram no tronco com frequência (pelo menos diária), branches de vida curta, integração contínua forte e feature flags (chaves que escondem o que ainda não está pronto). Favorece a entrega contínua.
• Merge × rebase: o merge junta dois caminhos com um commit de merge e preserva o histórico; o rebase reaplica os commits sobre outra base, criando commits novos, e deixa o histórico linear. Não se reescrevem commits que outras pessoas já baixaram: quem tinha os antigos fica com um histórico divergente. Rebasear os próprios commits locais sobre a main atualizada (git pull --rebase) é prática comum.
• Formas de concluir o pull request: merge commit, squash (junta todos os commits do branch num só) ou rebase.
• Proteção de branch: regras que impedem push direto na main e exigem aprovação e verificações do CI antes do merge. O arquivo CODEOWNERS indica quem precisa revisar cada parte do código.

Exemplo concreto: o filtro de urgentes, do branch ao merge

A equipe do sistema de protocolo usa um fluxo próximo do trunk-based, com pull requests curtos:

git switch main && git pull                 # parte da versão mais recente do tronco
git switch -c feat/filtro-urgentes          # branch curto, para uma mudança só
# ...dois ou três commits pequenos...
git push -u origin feat/filtro-urgentes     # envia o branch; o PR é aberto no GitHub (ou com gh pr create)

No pull request:

1. O CI roda o build, os testes e a análise de segurança. Se falhar, o merge fica bloqueado.
2. O CODEOWNERS chama automaticamente quem cuida do módulo de protocolo para revisar.
3. A revisora comenta uma linha: “e se a lista vier vazia?”. O autor acrescenta um teste e corrige.
4. Com a aprovação e o CI verde, o PR é concluído com squash: os commits do branch viram um só na main, com uma mensagem clara.
5. O branch é apagado. O filtro chegou à main ainda escondido por uma feature flag e foi ligado para todos dois dias depois.

Merge × rebase, em desenho:

Antes:          A---B---C          main
                     \
                      D---E        feature

Com merge:      A---B---C-------M  main     M é o commit de merge, com dois pais
                     \         /
                      D-------E

Com rebase:     A---B---C---D'--E' feature  D' e E' são commits novos, sobre C

Comparação: as estratégias e as formas de juntar

Uma boa revisão de código olha primeiro o que as ferramentas não pegam: a lógica atende ao requisito? há falhas de segurança (entrada sem validação, segredo no código)? o teste cobre o caso? o código é legível? Formatação e estilo ficam com linters automáticos. PRs pequenos são revisados melhor e mais depressa.

Como a FCC cobra

• Git distribuído × controle de versão centralizado.
• Merge × rebase e squash.
• Proteção de branch, aprovações e verificações do CI.
• Feature flags e integração contínua.

Pegadinhas

Explique com suas palavras

Explique a um gestor a diferença entre o Git Flow e o trunk-based development, e por que exigir pull request com revisão e testes antes do merge protege a produção.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

No Git Flow, o trabalho fica separado em várias linhas: cada funcionalidade é feita num ramo próprio, junta-se primeiro numa linha de integração e só depois de preparada vira uma versão oficial. É organizado para quem lança versões numeradas, mas, se os ramos demoram muito, juntar tudo no fim fica difícil. No trunk-based, todos juntam o trabalho na linha principal várias vezes por dia, em pedaços pequenos; o que não está pronto entra desligado, escondido por uma chave.

O pull request é um pedido de “confira antes de juntar”. Enquanto ele está aberto, os testes automáticos rodam e um colega lê a mudança. Se o teste falha ou o colega acha um problema, o código não entra. Assim, um erro é pego antes de chegar à versão que vai para os usuários, e fica registrado quem revisou e aprovou cada mudança.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

Num caso sobre a governança do código, proponha: main protegida (sem push direto), pull request obrigatório com pelo menos uma aprovação, CI com testes e análise de segurança como verificação obrigatória, CODEOWNERS para as áreas sensíveis e branches curtos. Escolha a estratégia pelo ritmo de entrega: Git Flow para versões planejadas; trunk-based com feature flags para entrega contínua. O histórico de PRs vira trilha de auditoria: quem mudou, quem revisou, quando.

Fontes da lição

• Edital nº 01/2026, Anexo II, DevOps, Plataforma de Desenvolvimento e Engenharia de Entrega (fontes/edital-01-2026.txt).
• Vincent Driessen, “A successful Git branching model” (2010), origem do Git Flow.
• Trunk Based Development (branches de vida curta e feature flags).
• Documentação do GitHub: pull requests e proteção de branches e do GitLab: merge requests.