Branching para times que precisam fechar pacote com precisão
Use xtreme-git-flow quando o time precisa explicar com precisão o que entrou na release, o que ainda está em validação de QA, qual hotfix retornou para as linhas ativas e por que develop e qa divergem. O modelo acrescenta processo; em troca, transforma release em evidência operacional.
Correções pedidas em QA voltam para a feature, então a versão aceita não se fragmenta entre branches de promoção.
Commits, arquivos e sentido funcional são checados antes que a divergência entre develop e qa vire surpresa operacional.
release-dev e release-qa transportam código entre ambientes; não deveriam concentrar decisões de produto.
Uma correção crítica só termina quando retorna às linhas ativas que poderiam reintroduzir o defeito.
Implementar, expor em desenvolvimento, homologar em QA, entrar oficialmente na release e equalizar os ambientes depois do aceite são decisões diferentes. O xtreme-git-flow dá a cada uma um caminho de branch, um ponto de revisão e um resultado verificável.
Só trabalho aceito em QA entra na release, então o pacote da sprint pode ser explicado sem vasculhar branches dispersas.
A branch qa valida a candidata antes de o PR congelado entrar na release. Reprovou? A correção volta para a feature.
Branches de promoção podem resolver integração. Elas não devem virar canal paralelo para comportamento de produto.
release-dev e release-qa tornam a movimentação entre ambientes explícita, em vez de depender de merges diretos sob pressão.
O delta entre develop e qa é calculado, classificado e tratado, em vez de virar especulação.
develop e qa são refrescadas periodicamente a partir da base estável para que resíduo antigo não vire normal.
O ganho não está em multiplicar nomes de branch. Está em disciplinar promoção, homologação, entrada em release, merge-back e leitura recorrente do delta entre develop e qa.
A adoção só se sustenta quando deixa rastros úteis. Estes são os quatro artefatos que o fluxo deve produzir ao final de uma sprint real.
Lista objetiva das features aceitas, PRs congelados e motivo de entrada na release.
release/2026.05-sprint-10: #2001, #2004, #2006Registro de que a feature passou por QA antes de entrar oficialmente no pacote.
feature/2005 -> release-qa/2005 -> qa -> releaseEvidência de que a versão aceita voltou para develop e qa depois da release.
merge-back/release/sprint-10 -> develop + qaClassificação final do que difere entre develop e qa, com responsáveis e tratamento.
2 commits exclusivos, 5 arquivos, 1 hotfix parcialGitHub Flow e trunk-based development favorecem integração e deploy frequentes. Git Flow formaliza linhas de release. xtreme-git-flow entra quando o desafio é provar composição, homologação e retorno de um pacote entre ambientes.
Melhor quando um PR aprovado já pode ficar perto de produção.
GitHub Flow funciona bem quando main é confiável, rollback é barato e o time não precisa fechar um pacote formal antes de publicar.
Combina melhor com produto de deploy frequente e pouca homologação manual.
Útil quando release branch importa, mas QA ainda cabe no mesmo ciclo.
Git Flow cria estrutura para release e hotfix, mas não resolve sozinho a pergunta sobre aceite em QA antes da entrada no pacote.
Atende melhor quando QA participa do ciclo, mas não opera como linha com aceite próprio.
Faz sentido quando trabalho incompleto pode ficar protegido por flags.
Trunk-based development funciona quando integração contínua é rotina, CI bloqueia regressões cedo e feature flags separam exposição de publicação.
Não é atalho para contexto que ainda depende de checklist manual por pacote.
Leitura prática: se a prioridade é integrar cedo e publicar com frequência, um fluxo mais leve costuma bastar. Se a necessidade é fechar pacote, validar em QA e administrar o delta entre ambientes, o xtreme-git-flow entrega mais controle.
O modelo se paga quando o time precisa explicar repetidamente o que está no pacote, o que QA aprovou, qual hotfix já foi propagado e por que duas linhas long-lived discordam.
Quando produto, suporte ou negócio perguntam exatamente o que entra em produção, release precisa ser mais do que nome de branch.
O modelo encaixa quando QA precisa de uma linha controlada, não apenas do que develop contém por acaso.
Quando uma feature depende de outra, a release precisa refletir o estado aceito, não apenas o estado mais novo.
Registros de promoção, hotfix e delta ajudam a explicar como o código se moveu, não apenas onde ele terminou.
A correção pode sair de main e chegar rápido em produção, mas a política força retorno para as linhas ativas antes do esquecimento.
Se develop e qa divergem com frequência, o relatório de delta vira instrumento de gestão, não pós-escrito técnico.
O fluxo alinha ambientes com produção, move a feature por exposição em desenvolvimento, validação em QA, entrada oficial na release, merge-back, propagação de hotfix e fechamento do delta.
As branches develop e qa recebem merge de main no início da sprint. A release vigente nasce dessa base.
A implementação nasce em feature/<id>-<descricao>, com PR congelado para a release como registro oficial da candidatura.
A branch release-dev sincroniza com develop, recebe revisão técnica e leva a feature ao ambiente de desenvolvimento.
A branch release-qa sincroniza com qa e disponibiliza a feature para validação funcional controlada.
Se QA rejeitar, a correção volta obrigatoriamente para a feature, mantendo uma única trilha legítima de implementação.
Somente após homologação o PR congelado é aprovado, e a feature passa a compor o pacote oficial da sprint.
Branches de merge-back devolvem para develop e qa a versão oficial consolidada na release.
Correção crítica sai de main, volta para as linhas ativas e a sprint encerra com apuração do delta e plano de tratamento.
Branches permanentes representam estados do produto. Branches transitórias carregam feature, promoção, merge-back ou correção emergencial. Essa separação evita que ajustes funcionais escapem para a branch mais conveniente.
Referência de estabilidade produtiva
Todo deploy produtivo parte daqui. Hotfix também nasce aqui.
Linha de integração técnica
Consolida entregas em andamento no ambiente de desenvolvimento.
Linha de homologação
Disponibiliza código controlado para validação funcional antes da composição oficial da release.
Pacote oficial da sprint
Recebe apenas features homologadas e aprovadas para a sprint.
Fonte de verdade funcional
Toda implementação e toda correção de QA devem voltar para cá.
Entrada controlada em develop
Resolve integração técnica sem contaminar a história funcional da feature.
Entrada controlada em qa
Leva a feature para homologação sem transformar qa em branch de desenvolvimento.
Retorno da versão oficial
Propaga a feature aceita na release de volta para develop e qa.
Correção crítica em produção
Sai de main, entra em produção e precisa ser propagada para todas as linhas ativas.
O primeiro diagrama mostra a política completa. O segundo mostra uma sprint com trabalho paralelo, conflito resolvido em branches de promoção, validação em QA e fechamento gradual do pacote.
A adoção funciona quando o time trata cada branch como contrato. Estas rotinas criam a disciplina mínima para manter o fluxo previsível ao longo das sprints.
develop, qa e release partem de main para que o time não comece a sprint herdando drift inexplicado.
O PR registra a candidatura, mas a aprovação espera aceite funcional. O pacote é composto por aceite, não por expectativa.
release-dev e release-qa tornam cada movimento explícito e mantêm trabalho de integração fora da história da feature.
A sprint termina com divergência classificada: esperada, pendente, hotfix parcial, resíduo histórico ou estado incorreto.
git checkout qa git pull git merge main git push git checkout develop git pull git merge main git push git checkout main git pull git checkout -b release/2026.05-sprint-10
git log --oneline develop ^qa git log --oneline qa ^develop git diff --name-status develop..qa git diff --name-status qa..develop git rev-list --left-right --count develop...qa
Esta seção incorpora o cenário documentado em ExemploReal.md: um origin bare local, três clones independentes, dois CRUDs e fechamento da sprint em main com tag. O objetivo é mostrar instalação, configuração e execução do xgf em um fluxo auditável.
O pacote oficial xtreme-git-flow-cli publica o comando xgf no ambiente global. Se preferir, também é possível executar sem instalação global com npx.
npm install -g xtreme-git-flow-cli xgf --help # alternativa sem instalação global npx xtreme-git-flow-cli --help
npm install -g xtreme-git-flow-cliO que faz: instala globalmente o pacote oficial publicado no npm.
O que produz: o comando xgf disponível no terminal para qualquer repositório.
xgf --helpO que faz: valida se o binário foi exposto corretamente e lista os comandos disponíveis.
O que produz: uma referência rápida com comandos, aliases e opções suportadas.
npx xtreme-git-flow-cli --helpO que faz: executa o pacote diretamente do npm sem instalação global prévia.
O que produz: acesso ad-hoc ao CLI para testes rápidos ou ambientes efêmeros.
Cada clone precisa registrar main, develop e qa em .git/xgf.config.json. Em uso manual, o caminho mais simples é rodar xgf config.
xgf config
xgf cfg --show
# arquivo salvo em .git/xgf.config.json
{
"branches": {
"main": "main",
"develop": "develop",
"qa": "qa"
},
"output": {
"mode": "compact"
}
}xgf configO que faz: abre o fluxo de configuração do repositório atual.
O que produz: o arquivo .git/xgf.config.json com nomes de main, develop, qa e modo de output.
Atalho / equivalente: Alias curto disponível: xgf cfg
xgf cfg --showO que faz: lê a configuração persistida e exibe os valores ativos para aquele clone.
O que produz: uma conferência rápida das branches estruturais antes de iniciar a sprint.
Atalho / equivalente: Equivale a xgf config --show
Team Lead e dona da release
Abre a sprint, alinha develop e qa com main, revisa as promoções, aprova features na release, executa merge-back e fecha a sprint com tag.
Opera sobre main, develop, qa e release/*.
Responsável pelo CRUD de clientes
Cria a feature 1001, adiciona src/resources/clientes.json, cobre o recurso com teste dedicado e promove a entrega para develop e qa.
Feature usada: feature/1001-clientes-crud.
Responsável pelo CRUD de produtos
Cria a feature 1002, adiciona src/resources/produtos.json, valida a entrega com teste próprio e repete o fluxo de promoção antes do aceite final.
Feature usada: feature/1002-produtos-crud.
O primeiro passo prepara qa, develop e release/2026.05-sprint-10 a partir de main.
git clone <origin> ana-tl cd ana-tl xgf cfg --show xgf ss 2026.05-sprint-10
git clone <origin> ana-tlO que faz: cria o clone da Team Lead a partir do remoto central.
O que produz: um diretório isolado onde Ana faz reviews, merges e fechamento da release.
cd ana-tlO que faz: entra no clone da TL para operar naquele repositório local.
O que produz: o contexto correto para rodar xgf naquele clone.
xgf cfg --showO que faz: confere as branches estruturais registradas para aquele clone.
O que produz: uma validação rápida da configuração antes da abertura da sprint.
Atalho / equivalente: Equivale a xgf config --show
xgf ss 2026.05-sprint-10O que faz: abre a sprint e prepara as linhas compartilhadas a partir de main.
O que produz: qa e develop alinhadas, mais a branch release/2026.05-sprint-10 pronta para receber features aprovadas.
Atalho / equivalente: Equivale a xgf sprint start -s 2026.05-sprint-10
A feature nasce da release limpa, gera checkpoint local e, se ainda houver pendências no push, permite escolher em árvore o recorte final antes de subir para origin e abrir as branches de promoção.
xgf fs 1001/clientes-crud 2026.05-sprint-10 npm test xgf ck xgf fp xgf fd 1001/clientes-crud xgf fq 1001/clientes-crud
xgf fs 1001/clientes-crud 2026.05-sprint-10O que faz: cria a feature de clientes a partir da release vigente.
O que produz: a branch feature/1001-clientes-crud já enviada para origin e pronta para desenvolvimento.
Atalho / equivalente: Equivale a xgf feature start -i 1001 -d clientes-crud -s 2026.05-sprint-10
npm testO que faz: roda os testes do exemplo antes da promoção.
O que produz: evidência local de que o CRUD e o loader continuam consistentes.
xgf ckO que faz: gera um checkpoint automático com git add -A e commit padronizado.
O que produz: um commit local com mensagem derivada da branch e do volume de arquivos alterados.
Atalho / equivalente: Equivale a xgf checkpoint
xgf fpO que faz: se houver alterações pendentes, abre uma TUI em árvore para selecionar arquivos, pastas ou tudo; depois envia a feature atual para origin.
O que produz: um commit único com o recorte escolhido quando necessário e origin/feature/1001-clientes-crud atualizado, evitando que a TL aprove uma cópia antiga.
Atalho / equivalente: Equivale a xgf feature push
xgf fd 1001/clientes-crudO que faz: cria a branch de promoção para o ambiente de desenvolvimento.
O que produz: release-dev/1001-clientes-crud pronta para PR em develop.
Atalho / equivalente: Equivale a xgf feature promote-dev -i 1001 -d clientes-crud
xgf fq 1001/clientes-crudO que faz: cria a branch de promoção para homologação.
O que produz: release-qa/1001-clientes-crud pronta para PR em qa.
Atalho / equivalente: Equivale a xgf feature promote-qa -i 1001 -d clientes-crud
O segundo CRUD repete o mesmo pipeline em paralelo e, no push, também pode escolher em árvore só o recorte final da entrega sem misturar as duas features.
xgf fs 1002/produtos-crud 2026.05-sprint-10 npm test xgf ck xgf fp xgf fd 1002/produtos-crud xgf fq 1002/produtos-crud
xgf fs 1002/produtos-crud 2026.05-sprint-10O que faz: cria a feature de produtos a partir da mesma release da sprint.
O que produz: feature/1002-produtos-crud isolada das demais entregas e pronta para evolução paralela.
Atalho / equivalente: Equivale a xgf feature start -i 1002 -d produtos-crud -s 2026.05-sprint-10
npm testO que faz: valida o CRUD de produtos antes das promoções.
O que produz: uma checagem local de regressão antes de gerar branches revisáveis.
xgf ckO que faz: cria o checkpoint automático da feature atual.
O que produz: um commit local padronizado para produtos.
Atalho / equivalente: Equivale a xgf checkpoint
xgf fpO que faz: se houver mudanças pendentes, abre a TUI em árvore para selecionar o que entra no commit final e sincroniza a feature com origin.
O que produz: um commit único com os itens escolhidos quando preciso e origin/feature/1002-produtos-crud pronto para aprovação futura pela TL.
Atalho / equivalente: Equivale a xgf feature push
xgf fd 1002/produtos-crudO que faz: abre a trilha de promoção para develop.
O que produz: release-dev/1002-produtos-crud candidata ao PR em develop.
Atalho / equivalente: Equivale a xgf feature promote-dev -i 1002 -d produtos-crud
xgf fq 1002/produtos-crudO que faz: abre a trilha de promoção para qa.
O que produz: release-qa/1002-produtos-crud candidata ao PR em qa.
Atalho / equivalente: Equivale a xgf feature promote-qa -i 1002 -d produtos-crud
Como a simulação é local, as PRs foram representadas com git merge --no-ff no clone da TL antes da aprovação oficial na release e do fechamento do pacote em main.
git merge --no-ff origin/release-dev/1001-clientes-crud -m "PR: release-dev/1001-clientes-crud -> develop" git merge --no-ff origin/release-qa/1001-clientes-crud -m "PR: release-qa/1001-clientes-crud -> qa" xgf fa 1001/clientes-crud 2026.05-sprint-10 xgf mb 1001/clientes-crud 2026.05-sprint-10 git merge --no-ff origin/release-dev/1002-produtos-crud -m "PR: release-dev/1002-produtos-crud -> develop" git merge --no-ff origin/release-qa/1002-produtos-crud -m "PR: release-qa/1002-produtos-crud -> qa" xgf fa 1002/produtos-crud 2026.05-sprint-10 xgf mb 1002/produtos-crud 2026.05-sprint-10 xgf dt xgf sc 2026.05-sprint-10 v2026.05.25-demo
git merge --no-ff origin/release-dev/1001-clientes-crud ...O que faz: simula o PR da promoção de clientes para develop no clone da TL.
O que produz: um merge commit explícito em develop, preservando a trilha da promoção.
git merge --no-ff origin/release-qa/1001-clientes-crud ...O que faz: simula o PR da promoção de clientes para qa.
O que produz: um merge commit em qa representando o aceite técnico da promoção para homologação.
xgf fa 1001/clientes-crud 2026.05-sprint-10O que faz: aprova formalmente a feature de clientes dentro da release.
O que produz: merge da feature em release/2026.05-sprint-10 após o ciclo de QA.
Atalho / equivalente: Equivale a xgf feature approve -i 1001 -d clientes-crud -s 2026.05-sprint-10
xgf mb 1001/clientes-crud 2026.05-sprint-10O que faz: abre as branches de merge-back da versão oficial de clientes.
O que produz: branches merge-back para equalizar develop e qa com o conteúdo já aceito na release.
Atalho / equivalente: Equivale a xgf merge-back -i 1001 -d clientes-crud -s 2026.05-sprint-10
git merge --no-ff origin/release-dev/1002-produtos-crud ...O que faz: simula o PR da promoção de produtos para develop.
O que produz: um merge commit explícito em develop para a segunda feature.
git merge --no-ff origin/release-qa/1002-produtos-crud ...O que faz: simula o PR da promoção de produtos para qa.
O que produz: um merge commit em qa, deixando a homologação da feature rastreável.
xgf fa 1002/produtos-crud 2026.05-sprint-10O que faz: aprova o CRUD de produtos na release oficial da sprint.
O que produz: merge da feature de produtos na release após o aceite funcional.
Atalho / equivalente: Equivale a xgf feature approve -i 1002 -d produtos-crud -s 2026.05-sprint-10
xgf mb 1002/produtos-crud 2026.05-sprint-10O que faz: prepara o retorno da versão oficial de produtos para as linhas compartilhadas.
O que produz: branches merge-back para develop e qa com o conteúdo já oficializado.
Atalho / equivalente: Equivale a xgf merge-back -i 1002 -d produtos-crud -s 2026.05-sprint-10
xgf dtO que faz: mede a divergência restante entre develop e qa.
O que produz: um relatório com commits exclusivos, diferenças de arquivos e leitura funcional do delta.
Atalho / equivalente: Equivale a xgf delta
xgf sc 2026.05-sprint-10 v2026.05.25-demoO que faz: fecha a sprint e publica o pacote em main.
O que produz: merge de release em main e criação da tag v2026.05.25-demo.
Atalho / equivalente: Equivale a xgf sprint close -s 2026.05-sprint-10 -t v2026.05.25-demo
Ao final da simulação, a release foi fechada com tag, os testes passaram em main e a estrutura de branches deixou claro o caminho de cada feature entre release-dev, release-qa, release e merge-back.
Identifica o fechamento operacional da sprint simulada.
v2026.05.25-demoOs dois recursos entram em main depois do aceite e do merge da release.
clientes + produtosA última checagem foi executada já com main atualizada.
npm test -> 3 pass / 0 failCheckpoint sem push não basta quando outra pessoa aprova a mesma feature de outro clone; se ainda houver pendências, o próprio push pode consolidar só o recorte certo antes da revisão remota.
xgf ck + xgf fp antes de xgf fa; ou xgf fp selecionando os arquivos finaisREADME.md package.json src/crudStore.js src/resourceLoader.js src/resources/.gitkeep src/resources/clientes.json src/resources/produtos.json src/server.js test/clientes-resource.test.js test/produtos-resource.test.js test/resource-loader.test.js
origin/main origin/develop origin/qa origin/release/2026.05-sprint-10 origin/feature/1001-clientes-crud origin/feature/1002-produtos-crud origin/release-dev/1001-clientes-crud origin/release-dev/1002-produtos-crud origin/release-qa/1001-clientes-crud origin/release-qa/1002-produtos-crud origin/merge-back/release/feature-1001-clientes-crud-to-dev origin/merge-back/release/feature-1001-clientes-crud-to-qa origin/merge-back/release/feature-1002-produtos-crud-to-dev origin/merge-back/release/feature-1002-produtos-crud-to-qa tag: v2026.05.25-demo
Conclusão operacional: xgf ck cria o commit local, e xgf fp envia a feature correta para revisão; se ainda houver pendências, ele também pode consolidar em árvore só os itens escolhidos antes do xgf fa.
No fechamento da sprint, o time lê a divergência em três camadas: commits exclusivos, arquivos alterados e classificação funcional. A saída é um plano de tratamento, não uma percepção vaga de ambientes desalinhados.
Identifica o que existe em um ambiente e não no outro, sem depender de memória coletiva.
git log --oneline develop ^qa git log --oneline qa ^develop git rev-list --left-right --count develop...qa
Mostra o delta de conteúdo entre as duas linhas, tornando a divergência observável por área afetada.
git diff --name-status develop..qa git diff --name-status qa..develop
A diferença técnica precisa virar classificação operacional. Isso evita tratar um delta legítimo como incidente e esconder uma divergência real.
O fechamento da sprint precisa registrar data, sprint de referência, volume de commits exclusivos, volume de arquivos divergentes, diferenças classificadas e plano de tratamento.
O modelo só é útil quando seu custo operacional é menor que o custo de releases pouco legíveis. Estas respostas deixam o trade-off explícito.
Não. As branches extras só fazem sentido porque separam decisões: expor em develop, expor em QA, aceitar na release, equalizar de volta e propagar hotfix. Sem essa disciplina, os nomes deixam de agregar controle.
Muitas vezes, sim. Se o time faz deploy contínuo, confia no CI, usa bem feature flags e não precisa de pacote aprovado separadamente, GitHub Flow ou trunk-based tendem a ser melhores.
Porque, sem isso, o comportamento aceito se reparte entre release-dev, release-qa e commits emergenciais. A feature preserva a história funcional; branches de promoção apenas movem e integram essa história.
Uma resposta repetível para quatro perguntas difíceis: o que está no pacote, o que QA aprovou, qual hotfix voltou para as linhas ativas e qual delta resta entre develop e qa.
A adoção falha quando o time copia nomes de branch, mas ignora disciplina: corrige direto na promoção, aprova release antes de QA ou esquece merge-back e fechamento do delta.
Porque divergência sem gestão vira trabalho escondido. O relatório permite classificar o que é legítimo, pendente, parcialmente propagado, histórico ou simplesmente incorreto.