Git Strategies para Times Produtivos: Do Trunk-Based ao Ship/Show/Ask

English summary: Your Git branching strategy is not a technical preference. It is an architectural decision that directly determines deploy frequency, lead time for changes, and mean time to recovery. This article provides a structured comparison of every major Git workflow -- Gitflow, GitHub Flow, trunk-based development, GitLab Flow, and Ship/Show/Ask -- with decision matrices tied to DORA metrics so teams can choose the strategy that matches their actual release cadence and team size, not the one they copied from a blog post in 2015.

Publicado em: Fevereiro de 2026 Tempo de leitura: 25 minutos Palavras-chave: #git #branching-strategy #trunk-based-development #github-flow #ship-show-ask #feature-flags #monorepo #ci-cd #dora-metrics #conventional-commits

Introducao

Quarenta e cinco minutos. Esse foi o tempo que um desenvolvedor senior gastou resolvendo um merge conflict na ultima sexta-feira antes de um deploy. O branch de feature tinha tres semanas de vida. A branch develop tinha evoluido em dezenas de commits paralelos. O resultado foi um diff de 847 linhas onde ninguem conseguia mais identificar o que era intencional e o que era efeito colateral.

Esse cenario se repete em milhares de times todos os dias. E a raiz do problema nao e Git. Nao e falta de habilidade tecnica. E a estrategia de branching.

A maioria dos times herda seu workflow de Git por acidente. Alguem leu o post original do Gitflow em 2010, implementou, e nunca mais questionou. Mesmo quando o time passou de deploys mensais para deploys diarios. Mesmo quando o time cresceu de 3 para 30 pessoas. Mesmo quando a infraestrutura evoluiu de servidores dedicados para Kubernetes com deploys automatizados.

A pesquisa State of DevOps do Google, que analisa dezenas de milhares de organizacoes, revela um dado que deveria fazer qualquer lider tecnico repensar seu workflow: times elite deployam 973 vezes mais frequentemente que times de baixa performance. A estrategia de branching nao e coincidencia nesse resultado.

Este artigo nao vai defender uma estrategia como "a melhor". Vai fazer algo mais util: fornecer um framework de decisao baseado em dados que conecta estrategia de branching a metricas DORA, tamanho de time e cadencia de release. Porque a melhor estrategia e aquela que seu time consegue seguir consistentemente e que otimiza para o que realmente importa: entregar valor para o usuario com seguranca.

Se voce ainda usa o mesmo workflow de Git de 2015, este artigo vai mostrar por que isso provavelmente esta custando 4-8 horas por desenvolvedor por semana em merge conflicts, code reviews bloqueados e deploys atrasados.

1. Por Que Sua Estrategia de Branching e uma Decisao Arquitetural

Existe uma tentacao de tratar branching strategy como uma preferencia de time, como tabs vs spaces ou Vim vs VS Code. Essa visao e fundamentalmente errada.

A estrategia de branching que voce escolhe determina:

• Frequencia de deploy. Gitflow com release branches naturalmente puxa para deploys semanais ou quinzenais. Trunk-based development puxa para deploys diarios ou por hora.
• Lead time for changes. Quanto tempo leva do primeiro commit ate producao? Branches de longa duracao adicionam dias ou semanas de latencia.
• Change failure rate. Merges grandes tem mais probabilidade de introduzir bugs. Merges pequenos e frequentes tem menos.
• Mean time to recovery (MTTR). Quando algo quebra, quao rapido voce consegue identificar e reverter? Com deploys frequentes de mudancas pequenas, o rollback e cirurgico. Com deploys infrequentes de mudancas massivas, o rollback e traumatico.

Essas quatro metricas sao exatamente as DORA metrics que o Google usa para classificar performance de engineering. E todas sao diretamente impactadas pela estrategia de branching.

Fonte: Google State of DevOps Report 2023

A correlacao entre branching strategy e essas metricas nao e acidental. Times elite usam predominantemente trunk-based development ou variacoes muito proximas. Times de baixa performance usam predominantemente Gitflow ou workflows com branches de longa duracao.

Isso nao significa que Gitflow e "ruim" e trunk-based e "bom". Significa que Gitflow foi projetado para um contexto especifico (releases mensais, times distribuidos com pouca comunicacao, sem CI/CD automatizado) e trunk-based foi projetado para outro contexto (deploys frequentes, times integrados, CI/CD robusto).

A pergunta correta nao e "qual e a melhor estrategia?" mas "qual estrategia e adequada para o meu contexto atual?"

2. Gitflow: O Que Resolveu, Por Que Esta Morrendo, Quando Ainda Faz Sentido

Vincent Driessen publicou o post "A successful Git branching model" em janeiro de 2010. O modelo proposto, que ficou conhecido como Gitflow, rapidamente se tornou o padrao de fato para times de desenvolvimento.

O Problema Que Gitflow Resolveu

Em 2010, o contexto era diferente:

• Deploys eram eventos. Exigiam coordenacao, janelas de manutencao, processos de aprovacao.
• CI era primitivo. Jenkins existia, mas CI/CD como conhecemos hoje era raro.
• Times eram distribuidos com comunicacao assincrona. Branches protegiam trabalho em progresso.
• Rollbacks eram dificeis. Sem containers, sem orquestracao, reverter um deploy era arriscado.

Gitflow resolvia esses problemas com uma estrutura clara:

                    +------------------+
                    |     main         |  (producao)
                    +--------+---------+
                             |
              +--------------+---------------+
              |                              |
     +--------v---------+         +----------v---------+
     |    hotfix/xxx    |         |    release/1.0     |
     +--------+---------+         +----------+---------+
              |                              |
              +-------->+------------+<------+
                        |   develop  |  (integracao)
                        +-----+------+
                              |
         +--------+-----------+------------+--------+
         |        |           |            |        |
    +----v---+ +--v-----+ +---v----+ +-----v--+ +---v----+
    |feat/A  | |feat/B  | |feat/C  | |feat/D  | |feat/E  |
    +--------+ +--------+ +--------+ +--------+ +--------+

Branches principais:

• main: sempre reflete producao.
• develop: branch de integracao para features.

Branches de suporte:

• feature/*: desenvolvidas a partir de develop, mergeadas de volta.
• release/*: preparacao de release a partir de develop.
• hotfix/*: correcoes urgentes a partir de main.

Por Que Gitflow Esta Morrendo

O proprio Vincent Driessen adicionou uma nota ao post original em 2020:

"If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team."

Os problemas de Gitflow em contextos modernos:

1. Branches de longa duracao criam merge hell. Uma feature branch que vive por duas semanas diverge significativamente de develop. O merge nao e um evento trivial; e uma negociacao complexa entre mudancas conflitantes.

2. O modelo assume releases infrequentes. Com CI/CD, a distincao entre develop e main perde sentido. Se voce deploya toda mudanca que passa no CI, por que manter duas branches "principais"?

3. Overhead cognitivo e processual. Criar release branches, fazer cherry-picks, manter hotfixes sincronizados com develop e main: cada passo e uma oportunidade para erro.

4. Incentiva batching. Times acumulam features ate a "proxima release" em vez de deployar incrementalmente. Batching aumenta risco.

Quando Gitflow Ainda Faz Sentido

Gitflow nao morreu. Ele tem nichos legitimos:

• Software empacotado com versoes explicitas. SDKs, bibliotecas, frameworks onde versoes (1.0, 1.1, 2.0) sao parte da identidade do produto.
• Multiplas versoes em producao simultaneamente. Software on-premise onde clientes rodam versoes diferentes e voce precisa manter branches de suporte (1.x, 2.x).
• Regulacao pesada. Setores como saude e financeiro onde cada release precisa de auditoria e aprovacao formal.
• Times com pouca maturidade de CI/CD. Se voce nao tem CI/CD confiavel, a estrutura de Gitflow oferece checkpoints manuais.

Se nenhum desses cenarios descreve seu time, Gitflow provavelmente e overhead desnecessario.

3. GitHub Flow: A Simplificacao Que Mudou Tudo

GitHub Flow, proposto pelo GitHub em 2011, foi uma reacao direta a complexidade de Gitflow. A proposta era radical na simplicidade: uma branch principal, branches de feature curtas, pull requests, e deploy direto de main.

                +------------------------------------------+
                |                  main                    |
                +----+-------------+-------------+---------+
                     |             |             |
                +----v----+   +----v----+   +----v----+
                | feat/A  |   | feat/B  |   | fix/C   |
                +----+----+   +----+----+   +----+----+
                     |             |             |
                     v             v             v
                   [PR]          [PR]          [PR]
                     |             |             |
                     +-------------+-------------+
                                   |
                                   v
                            [CI/CD + Deploy]

Regras do GitHub Flow

1. Main e sempre deployavel. A qualquer momento, main representa producao.
2. Branches de feature sao curtas. Horas ou poucos dias, nunca semanas.
3. Pull requests para code review. Nenhum codigo vai direto para main.
4. Deploy apos merge. Assim que o PR e mergeado, o codigo vai para producao.

Vantagens

• Simplicidade radical. Uma branch principal, um tipo de branch de trabalho, um fluxo.
• Incentiva integracao frequente. Branches curtas significam merges pequenos.
• Feedback rapido. Deploy imediato significa que problemas aparecem rapidamente.

Limitacoes

• Assume CD robusto. Se seu CI/CD nao e confiavel, deployar cada merge e arriscado.
• Sem ambiente de staging explicito. O modelo nao define onde testar antes de producao.
• Pressao no code review. Todo merge vai para producao; reviews se tornam gate critico.

GitHub Flow e ideal para times pequenos a medios (3-15 devs) com CD maduro e cultura de code review estabelecida.

4. Trunk-Based Development: Como Times Elite Deployam Dezenas de Vezes por Dia

Trunk-based development leva a simplificacao ao extremo: todos commitam diretamente na branch principal (trunk/main), varias vezes por dia, e cada commit e potencialmente deployavel.

     main (trunk)
     ==============================================================
         |     |     |     |     |     |     |     |     |     |
         v     v     v     v     v     v     v     v     v     v
        [c1]  [c2]  [c3]  [c4]  [c5]  [c6]  [c7]  [c8]  [c9]  [c10]
         |                       |                       |
         v                       v                       v
      [Deploy]                [Deploy]                [Deploy]

     (Short-lived feature branches, if used)

         +----[feat/A]----+
         |                |
     ----+----------------+------>  main
         ^                ^
         |   (< 1 day)    |
         +----------------+

Caracteristicas Fundamentais

1. Commits frequentes e pequenos. Em vez de acumular trabalho em uma feature branch, desenvolvedores integram mudancas pequenas varias vezes por dia.

2. Feature flags para codigo incompleto. Codigo nao pronto para usuarios vai para producao, mas atras de uma flag que o desativa.

// Codigo em producao, mas desativado para usuarios
async function processPayment(order: Order) {
  if (await featureFlags.isEnabled('new-payment-processor', order.userId)) {
    return newPaymentProcessor.process(order);
  }
  return legacyPaymentProcessor.process(order);
}

3. CI extremamente rapido e confiavel. Se o CI demora 30 minutos, trunk-based development nao funciona. O feedback precisa ser rapido (idealmente < 10 minutos) para nao bloquear integracao.

4. Pair programming ou review sincrono. Com commits diretos na main, a revisao acontece antes do commit (pair programming) ou imediatamente apos (revisao sincrona).

Por Que Times Elite Usam Trunk-Based

A pesquisa do Google mostra que trunk-based development correlaciona fortemente com alta performance porque:

• Elimina merge conflicts. Sem branches de longa duracao, nao ha divergencia significativa.
• Reduz tamanho de mudancas. Commits pequenos sao mais faceis de revisar, testar e reverter.
• Acelera feedback loop. Problemas aparecem em minutos, nao em semanas.
• Simplifica modelo mental. Uma branch, um fluxo, menos overhead cognitivo.

Quando Trunk-Based Nao Funciona

• CI/CD imaturo ou lento. Se o pipeline demora mais de 15 minutos, o fluxo quebra.
• Falta de feature flags. Sem flags, voce nao consegue integrar codigo incompleto.
• Times distribuidos sem comunicacao sincrona. Pair programming e review sincrono exigem overlap de horario.
• Cultura de code review assincrono profundamente enraizada. A transicao requer mudanca cultural significativa.

5. GitLab Flow: Environment Branches e o Meio-Termo

GitLab Flow tenta ocupar o espaco entre a rigidez de Gitflow e a simplicidade de GitHub Flow, adicionando o conceito de environment branches.

     +------------+     +------------+     +------------+
     |   main     | --> | staging    | --> | production |
     +-----+------+     +-----+------+     +------------+
           |                  |
           |                  |
     +-----v------+           |
     |  feature/X |           |
     +-----+------+           |
           |                  |
           v                  |
         [PR/MR]              |
           |                  |
           +-------> main ----+

Modelos de GitLab Flow

Environment Branches:

• main: codigo revisado e testado.
• staging: ambiente de pre-producao.
• production: producao.

Deploys acontecem por merge entre branches de ambiente.

Release Branches (para software versionado):

     main
       |
       +---> release/1.0 ---> release/1.1
       |
       +---> release/2.0

Vantagens

• Mapeamento explicito para ambientes. Cada branch representa um ambiente real.
• Controle de promocao. Codigo flui de main para staging para production com gates.
• Flexibilidade. Adapta-se tanto a CD quanto a releases agendadas.

Limitacoes

• Mais branches para gerenciar. Nao tao simples quanto GitHub Flow.
• Potencial para divergencia. Se staging e production divergem, surgem problemas.
• Merge ceremonies. Cada promocao de ambiente e um merge que precisa de atencao.

6. Ship/Show/Ask: O Modelo Baseado em Confianca

Ship/Show/Ask, proposto por Rouan Wilsenach, nao e exatamente uma estrategia de branching. E um protocolo de decisao sobre quando fazer merge e quando pedir review.

A ideia central: nem toda mudanca precisa do mesmo nivel de escrutinio. Algumas podem ir direto para producao (Ship). Algumas devem ser mostradas depois de mergeadas (Show). Algumas precisam de aprovacao antes (Ask).

                           +-------------------+
                           |  Mudanca pronta   |
                           +---------+---------+
                                     |
              +----------------------+----------------------+
              |                      |                      |
              v                      v                      v
        +-----+------+        +------+------+        +------+------+
        |    SHIP    |        |    SHOW     |        |     ASK     |
        +-----+------+        +------+------+        +------+------+
              |                      |                      |
              v                      v                      v
         Merge direto           Merge +              Abrir PR
         em main               notificar             e aguardar
              |                  team                 review
              |                      |                      |
              +----------------------+----------------------+
                                     |
                                     v
                                [Deploy]

Categorias

Ship (Enviar diretamente):

• Mudancas triviais: typos, formatting, atualizacao de dependencias.
• Mudancas que voce tem total confianca.
• Mudancas em areas onde voce e o expert.

Show (Mostrar depois):

• Mudancas que o time deve saber, mas nao precisa aprovar.
• Refatoracoes em areas conhecidas.
• Features pequenas seguindo padroes estabelecidos.

Ask (Perguntar antes):

• Mudancas em areas criticas ou desconhecidas.
• Decisoes arquiteturais.
• Mudancas que afetam outros times.
• Primeira contribuicao em uma area do codigo.

Como Funciona na Pratica

# SHIP: merge direto
git checkout main
git pull origin main
git merge --no-ff feature/fix-typo
git push origin main

# SHOW: merge + notificacao
git checkout main
git merge --no-ff feature/refactor-parser
git push origin main
# Notifica no Slack: "Merged refactor do parser - veja commit abc123 se quiser"

# ASK: PR tradicional
git push origin feature/new-auth-flow
gh pr create --title "feat: new auth flow" --body "..."
# Aguarda review antes de merge

Por Que Ship/Show/Ask Esta Ganhando Tracao

• Escala confianca, nao processo. A medida que devs ganham experiencia em areas do codigo, precisam de menos gates.
• Reduz overhead de review. Nem toda mudanca precisa de 2 approvals.
• Acelera delivery. Mudancas triviais nao ficam bloqueadas por dias esperando review.
• Mantem seguranca onde importa. Mudancas criticas ainda passam por escrutinio.

Prerequisitos

• Cultura de confianca e responsabilidade. Se erros sao punidos, ninguem vai Ship.
• Observabilidade forte. Se algo quebrar, precisa ser detectado rapidamente.
• Feature flags. Para reverter mudancas problematicas sem rollback de deploy.

7. Feature Flags vs Feature Branches: Desacoplando Deploy de Release

A maioria dos times confunde dois conceitos distintos:

• Deploy: colocar codigo em producao.
• Release: tornar funcionalidade disponivel para usuarios.

Feature branches acoplam deploy e release. Voce so deploya quando a feature esta pronta para usuarios. Feature flags desacoplam: voce deploya codigo incompleto, mas controla via flag quando ele e ativado.

Feature Branches: O Modelo Acoplado

Desenvolvimento        [==========Feature Branch==========]
Deploy/Release                                             [X]
                       |<-------- 2 semanas --------------->|

Problemas:

• Branch vive semanas, acumulando divergencia.
• Merge no final e arriscado e demorado.
• Deploy e um "big bang" com muitas mudancas.

Feature Flags: O Modelo Desacoplado

Desenvolvimento  [=][=][=][=][=][=][=][=][=]  (commits pequenos)
Deploy           [D] [D] [D] [D] [D] [D] [D]  (deploys frequentes)
Release                                   [R]  (flag ativada)

O codigo vai para producao em incrementos pequenos, atras de uma flag. Quando a feature esta pronta, a flag e ativada.

Implementacao Pratica de Feature Flags

// Servico de feature flags (simplificado)
interface FeatureFlagService {
  isEnabled(flagKey: string, context?: FlagContext): Promise<boolean>;
}

// Uso no codigo
async function renderCheckout(user: User, cart: Cart) {
  const showNewPayment = await flags.isEnabled('new-payment-ui', {
    userId: user.id,
    userTier: user.tier,
    region: user.region
  });

  if (showNewPayment) {
    return <NewPaymentFlow cart={cart} />;
  }
  return <LegacyPaymentFlow cart={cart} />;
}

Estrategias de Rollout

Ferramentas Populares

• LaunchDarkly: Enterprise, robusto, caro.
• Unleash: Open source, self-hosted.
• Flagsmith: Open source com opcao hosted.
• ConfigCat: Simples, preco acessivel.
• Flipper (Ruby), Flipt: Alternativas leves.

Lifecycle de uma Feature Flag

1. Criar flag (desabilitada)
2. Desenvolver atras da flag
3. Deploy para producao (flag off)
4. Rollout gradual (1% -> 10% -> 50% -> 100%)
5. Flag 100% on por X dias sem problemas
6. Remover flag e codigo legado (tech debt cleanup)

A etapa 6 e critica e frequentemente negligenciada. Flags abandonadas viram divida tecnica.

8. Monorepo: Estrategias de Branching em Escala

Monorepos (todos os projetos em um unico repositorio) introduzem desafios especificos para branching. Quando centenas de desenvolvedores trabalham no mesmo repo, estrategias que funcionam para times pequenos podem colapsar.

Desafios de Monorepo

• CI lento. Rodar todos os testes para cada commit e inviavel.
• Ownership difuso. Quem aprova PRs que tocam multiplos projetos?
• Merge conflicts em escala. Muitos devs modificando arquivos compartilhados.

Affected Projects: Rode Apenas o Necessario

Ferramentas como Nx e Turborepo calculam quais projetos sao afetados por uma mudanca.

# Nx: lista projetos afetados pelo commit
npx nx affected:apps --base=origin/main --head=HEAD

# Turborepo: roda testes apenas para afetados
npx turbo run test --filter=...[origin/main]

Configuracao Nx (nx.json):

{
  "affected": {
    "defaultBase": "origin/main"
  },
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx/tasks-runners/default",
      "options": {
        "cacheableOperations": ["build", "test", "lint"],
        "parallel": 5
      }
    }
  }
}

Configuracao Turborepo (turbo.json):

{
  "pipeline": {
    "build": {
      "dependsOn": ["^build"],
      "outputs": ["dist/**", ".next/**"]
    },
    "test": {
      "dependsOn": ["build"],
      "outputs": []
    },
    "lint": {
      "outputs": []
    }
  }
}

CODEOWNERS para Ownership Claro

# CODEOWNERS
# Formato: padrao de arquivos -> owners

# Core packages
/packages/core/**        @core-team
/packages/auth/**        @security-team

# Apps
/apps/web/**             @web-team
/apps/mobile/**          @mobile-team

# Shared configs
/package.json            @platform-team
/tsconfig.base.json      @platform-team

Com CODEOWNERS, PRs automaticamente requisitam review dos times corretos.

Branching em Monorepo

A maioria dos monorepos bem-sucedidos usa trunk-based development porque:

• Branches de longa duracao sao ainda mais problematicas em escala.
• Affected project calculation funciona melhor com main como base.
• Feature flags permitem integrar codigo incompleto sem quebrar outros projetos.

main (trunk)
  |
  +-- [commit: apps/web] --> affected: web, shared-utils
  |
  +-- [commit: packages/core] --> affected: ALL apps that depend on core
  |
  +-- [commit: apps/mobile] --> affected: mobile only

9. Conventional Commits: Padronizacao Que Habilita Automacao

Conventional Commits e uma especificacao para mensagens de commit que habilita geracao automatica de changelogs, versionamento semantico e melhor navegacao de historico.

Formato

<tipo>[escopo opcional]: <descricao>

[corpo opcional]

[rodape(s) opcional(is)]

Tipos Principais

Exemplos Praticos

# Feature simples
git commit -m "feat(auth): add password reset flow"

# Bug fix
git commit -m "fix(cart): correct total calculation with discounts"

# Breaking change (MAJOR version)
git commit -m "feat(api)!: change response format for /users endpoint

BREAKING CHANGE: response now returns array instead of object"

# Commit com corpo explicativo
git commit -m "refactor(parser): extract validation logic

Move validation from Parser class to dedicated Validator.
This prepares for adding custom validation rules in next sprint.

Refs: JIRA-1234"

Automacao com Conventional Commits

Geracao de changelog:

# Com standard-version ou semantic-release
npx standard-version

# Gera CHANGELOG.md automaticamente:
# ## [1.2.0] - 2026-02-09
# ### Features
# * **auth:** add password reset flow
# ### Bug Fixes
# * **cart:** correct total calculation with discounts

Versionamento automatico:

// package.json
{
  "scripts": {
    "release": "standard-version",
    "release:minor": "standard-version --release-as minor",
    "release:major": "standard-version --release-as major"
  }
}

Validacao com commitlint:

// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional'],
  rules: {
    'type-enum': [2, 'always', [
      'feat', 'fix', 'docs', 'style', 'refactor',
      'perf', 'test', 'chore', 'ci', 'revert'
    ]],
    'scope-case': [2, 'always', 'kebab-case'],
    'subject-max-length': [2, 'always', 72]
  }
};

Husky hook para validar:

# .husky/commit-msg
#!/bin/sh
npx --no -- commitlint --edit "$1"

10. CI/CD: O Pipeline Que Forca o Workflow

A estrategia de branching so funciona se o pipeline de CI/CD a enforcar. Sem automacao, regras viram sugestoes que ninguem segue.

Pipeline para Trunk-Based Development

# .github/workflows/trunk.yml
name: Trunk-Based CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Type Check
        run: npm run typecheck

      - name: Test
        run: npm run test:ci

      - name: Build
        run: npm run build

  deploy:
    needs: validate
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - name: Deploy to Production
        run: |
          # Deploy automatico apos merge em main
          ./scripts/deploy.sh production

Protecao de Branch

# Configuracao via GitHub Branch Protection Rules
# Settings > Branches > Add rule

# Para main:
- Require pull request reviews: 1 (ou 0 para Ship/Show/Ask)
- Require status checks:
  - validate
- Require branches to be up to date: true
- Include administrators: true

Checks Que Devem Bloquear Merge

Total: menos de 15 minutos para trunk-based funcionar.

11. Como IA Muda Code Review e Decisoes de Branching

Com ferramentas de code review assistidas por IA (GitHub Copilot, CodeRabbit, Sourcery, etc.), o landscape de code review esta mudando.

O Que IA Faz Bem em Code Review

• Deteccao de bugs obvios. Off-by-one errors, null checks faltando.
• Sugestoes de estilo. Formatacao, naming conventions.
• Identificacao de padroes. "Este codigo e similar a X, considere reutilizar."
• Resumo de PRs grandes. "Este PR adiciona feature X modificando Y arquivos."

O Que IA Nao Faz (Ainda)

• Validar decisoes arquiteturais. A IA nao entende o contexto do negocio.
• Avaliar trade-offs. "Isso e simples vs extensivel" requer julgamento humano.
• Verificar corretude de dominio. A IA nao sabe que regra de negocio o codigo deveria implementar.

Impacto em Branching Strategy

Com IA fazendo parte do review, alguns times estao:

• Reduzindo numero de reviewers humanos. IA catch o trivial, humanos focam no importante.
• Movendo mais para Ship/Show. Se IA validou o obvio, menos precisa de Ask.
• Acelerando review cycles. PRs menores com IA review sao processados mais rapido.

# Exemplo: IA review antes de humano
# .github/workflows/ai-review.yml
name: AI Pre-Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - name: Run AI Review
        uses: coderabbitai/ai-pr-reviewer@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          openai_api_key: ${{ secrets.OPENAI_API_KEY }}

12. Matriz de Decisao: Escolhendo a Estrategia Certa

Depois de analisar cada estrategia, aqui esta o framework para escolher:

Por Tamanho de Time

Por Cadencia de Release

Por Maturidade de CI/CD

Por Tolerancia a Risco

Matriz Consolidada

                    CI/CD Maturity
                    Low -------- Medium -------- High
                    |             |               |
   Baixa     |  Gitflow    GitLab Flow    GitHub Flow
   Tolerancia      |             |               |
   a Risco   |     |             |               |
                   |             |               |
   Media     | GitHub Flow  GitHub Flow  Ship/Show/Ask
                   |             |               |
                   |             |               |
   Alta      | GitHub Flow Ship/Show/Ask  Trunk-based

13. Migrando Entre Estrategias

A transicao entre estrategias e tao importante quanto a escolha. Migracoes abruptas criam caos.

De Gitflow para GitHub Flow

Semana 1-2: Anunciar mudanca, treinar time
Semana 3-4: Parar de criar release branches
Semana 5-6: Merge develop em main, eliminar develop
Semana 7+:  Operar em GitHub Flow puro

Passos:

1. Congele novas feature branches longas.
2. Merge todas as branches de feature existentes em develop.
3. Merge develop em main.
4. Configure branch protection em main.
5. Elimine develop e release branches.

De GitHub Flow para Trunk-Based

Fase 1: Introduza feature flags (2-4 semanas)
Fase 2: Reduza tamanho de PRs (meta: < 200 linhas)
Fase 3: Acelere CI (meta: < 10 minutos)
Fase 4: Experimente Ship/Show/Ask
Fase 5: Comece com commits diretos em main (com pair/mob)

Prerequisitos antes de cada fase:

• Fase 1: Escolher e integrar ferramenta de feature flags.
• Fase 2: Definir metricas de PR (LOC, tempo de review).
• Fase 3: Implementar affected tests, cache de CI.
• Fase 4: Estabelecer criterios de Ship vs Show vs Ask.
• Fase 5: Praticar pair programming, garantir observabilidade.

Rollback de Estrategia

Se a nova estrategia nao funcionar, tenha um plano de rollback:

# Voltando para GitHub Flow de Trunk-Based
1. Reintroduza requisito de PR para main
2. Configure branch protection rules
3. Comunique mudanca ao time
4. Mantenha feature flags (nao jogue fora)

Conclusao: A Estrategia Certa e a Que Seu Time Segue

Depois de analisar cinco estrategias, centenas de paginas de pesquisa do Google, e dezenas de times em producao, a conclusao e anticlimacticamente simples:

A melhor estrategia de branching e aquela que seu time consegue seguir consistentemente.

Gitflow em um time disciplinado que faz releases mensais funciona perfeitamente. Trunk-based development em um time sem CI/CD e um desastre esperando acontecer. A estrategia nao existe no vacuo; existe no contexto do seu time, sua infraestrutura, sua cultura.

O que os dados mostram claramente:

1. Branches de longa duracao sao o inimigo. Independente da estrategia, mantenha branches curtas (horas a dias, nunca semanas).

2. CI/CD determina o que e possivel. Invista em CI rapido e CD confiavel antes de mudar a estrategia de branching.

3. Feature flags desacoplam deploy de release. Esse desacoplamento e o que permite integracao frequente sem risco.

4. Confianca escala melhor que processo. Ship/Show/Ask e um modelo mental mais do que uma estrategia; aplique-o em qualquer workflow.

5. Metricas DORA sao o norte. Meca deploy frequency, lead time, change failure rate e MTTR. A estrategia que melhora essas metricas e a certa para voce.

Se voce saiu deste artigo com uma coisa, que seja esta: pare de tratar branching strategy como uma configuracao de Git. Trate como uma decisao arquitetural que impacta diretamente a velocidade e seguranca do seu delivery.

E se voce ainda esta usando o mesmo workflow de 2015, talvez seja hora de questionar por que.

Referencia Rapida: Comparativo de Estrategias

Checklist de Migracao

Antes de Mudar de Estrategia

• Medir metricas DORA atuais (baseline)
• Avaliar maturidade de CI/CD
• Identificar feature flag solution
• Treinar time na nova estrategia
• Definir criterios de sucesso
• Planejar rollback

Durante a Migracao

• Comunicar claramente expectativas
• Manter branch protection rules
• Monitorar metricas de PR (tamanho, tempo de review)
• Coletar feedback do time semanalmente
• Ajustar conforme necessario

Apos a Migracao

• Comparar metricas DORA com baseline
• Documentar licoes aprendidas
• Remover artefatos da estrategia antiga
• Refinar guidelines baseado em experiencia
• Celebrar melhorias (se houver)

Sua estrategia de branching nao e um detalhe tecnico. E uma decisao arquitetural que determina quao rapido voce pode entregar valor e quao seguro e fazer isso. Escolha deliberadamente, meca consistentemente, e ajuste conforme o contexto muda.