1. O documento discute diferentes modelos de branches em sistemas de controle de versão, comparando seus prós e contras. 2. Os modelos incluem branch para release, branch por release, branch por componente, branch por feature e branch por time. 3. O modelo "branch como essência, sempre" propõe um modelo misto usando várias "pistas paralelas" com diferentes estratégias de branch.

1. Uso de Branches no Sistema de
Controle de Versão
(Em Busca do Modelo Ideal para a sua empresa)
(2012/03/22)
Marcio Marchini
marcio@BetterDeveloper.net

2. Branches
1. A criação de um branch representa uma mudança na política de
codificação. (Nova versão? Novo cliente? Etc)
2. Modelos de branching distintos servem melhor para situaçãoes distintas
(times/empresas/produtos distintos)

3. Bibliografia Usada / Nomenclatura & Classificação
1. “Continuous Delivery” (livro Amazon). Especialmente o Capítulo 14 (e 13).
2. "Advanced SCM Branching Strategies" http://www.vance.com/steve/perforce/
Branching_Strategies.html
3. "Streamed Lines: Branching Patterns for Parallel Software Development"http://
www.cmcrossroads.com/bradapp/acme/branching/
4. "Version Control for Multiple Agile Teams" http://www.infoq.com/articles/agile-
version-control
5. "Feature Branch" http://martinfowler.com/bliki/FeatureBranch.html
6. "The Importance of Branching Models in SCM” http://framework.zend.com/
wiki/download/attachments/1129/SCMBranchingModels.pdf?version=1
7. "A successful Git branching model” http://nvie.com/posts/a-successful-git-
branching-model/ , http://github.com/downloads/nvie/gitflow/Git-branching-
model.pdf
8. “TFS Branching Guide” http://vsarbranchingguide.codeplex.com/releases/
view/38849

4. Principais modelos de Branches
1. Branch para (fechar o) Release (ao congelar para a release)
2. Branch por (inicio de) Release (ao se iniciar o trabalho da release)
3. Branch por Componente
4. Branch por Feature
5. Branch por Time
6. Branch (quase) Nunca
7. Branch como Essência, Sempre
8. Modelos Mistos

5. Branch para (congelar pra) Release – Visão Geral
1. Descrição
• Imediatamente antes de empacotar (para um RC – Release Candidate)
• Trunk é o mainline (baseline)
• Branch quando se congela o Release Candidate. Vira “manutenção”. Branches =
Pequenos apêndices numa coluna vertebral
• Bug fixes importantes são corrigidos no branch (apêndice cresce ligeiramente) e é dado
merge de volta no trunk
2.0 (RC)1.0 (RC) 3.0 (RC)
Time já começando na 2.0
Correções/ajustes/patches

6. Branch para (congelar pra) Release – Pros e Cons
1. Pros
• Branches têm vida curta. Baixo overhead (não custoso)
• Amigável a Continuous Delivery (trunk tem continuidade, trends ok no jenkins etc)
• Não bloqueia novo desenvolvimento (paraleliza com manutenção / ajustes)
• Fácil de dar manutenção a versões antigas em campo (commit no mini-branch /
apêndice, merge no trunk se necessário)
2. Contras / Ressalvas / Dicas
• Times diferentes têm velocidades diferentes, não conseguem entregar
simultaneamente. Use Branch por Componente nesse caso.
• Trunk/mainline tem alto risco de se tornar quebrado sempre. Necessita Continuous
Integration para prevenir. Ou: esconder/desabilitar features incompletas (mais
detalhes no livro Continuous Delivery).
• Impossível escolher seletivamente features a incorporar (ex: Linux Kernel / Linus).
Nesse caso, veja Branch por Feature.
• Necessidade de aplicar um patch em N branches de releases em campo (e.g. bug na
12.0 tem que ser corrigido na 13.0, 14.0, 15.0 e trunk)

7. Branch por Componente
1. Descrição
• Arquitetura modular, cada componente macro em um branch
2. Pros
• Lida bem com times diferentes com velocidades diferentes
• Possibilita times dispersos geograficamente
3. Contras / Ressalvas / Dicas
• Se você possui um time por componente, isso se torna Branch por Time.
• Idealmente as entregas deveriam ser de binários (LIB, DLL, JAR)

8. Branch por (início de) Release – Visão Geral
1. Descrição
• Criado no início do desenvolvimento da Release
• Estrutura em escada (branch de branch de branch…) ou 1 degrau que precisa dar merge
de volta sempre.
• Cada novo release começa com um branch/degrau a partir da anterior
Des 1.0
Des. 2.0
Des. 3.0
Forma 1: Sem mainline. Má
utilização do VCS (mas não
precisa merge de volta em
trunk)
Des. 2.0
Forma 2: Com
mainline. Requer
merges completos.
Mas como fica o
patch da 2.0 após
3.0 começar?
Des. 3.0
Era assim na Ch*****c, por
exemplo.
1.0 2.0 3.0
Correções/
ajustes/
patches
Correções/
ajustes/
patches

9. Branch por (início de) Release – Pros e Contras
1. Pros
• Suporta patch de versões antigas em campo (no degrau correspondente da escada)
2. Contras / Ressalvas / Dicas
• Na forma #1 Não existe o conceito de mainline - Impossível ver/obter trends etc no
Build Contínuo. Na forma #2 esse problema é aliviado (às custas do mega merge
necessário ao fim de cada versão) mas existem saltos grandes de trend no trunk (pois
parte do histórico está em outro branch)
• Difícil ver que código é comum entre releases
• Trabalhoso fazer patch de versão antiga – precisa propagar em todos os degraus
subsequentes.
• Trabalhoso demais se os Releases são frequentes
• Não promove desenvolvimento em paralelo

10. Branch por Feature – Visão Geral
1. Descrição
• Explicado bem em http://bit.ly/bBjxbS
• Cada User Story / Use Case é um Branch que precisa ter um Aceite
• Líder técnico etc deveria revisar e aceitar/recusar no mainline

11. Branch por Feature – Pros e Cons
1. Pros
• Promove mainline sempre estável enquanto times trabalham em features distintas
• Trabalho incompleto não afeta outros membros (pois é localizado no branch)
• Histórico no controle de versão semanticamente mais rico (cada branch & merge no
trunk é um bug fix completo ou User Story Completa)
• Mapeia diretamente com atividade Kanban
• Fácil de fazer em um DVCS como Git. Modelo promovido pelo GitHub (“fork”)
2. Contras / Ressalvas / Dicas
• Mudanças no mainline devem ser mergeadas em todas as branches diariamente.
• Branches precisam ser de curta duração (1 sprint)
• Nenhum novo branch até que a User Story anterior seja considerada DONE
• Refactorings divergem. Refatorações devem ser mergeadas imediatamente.
• Pra Build Contínuo é preciso emular um “candidato total” com trunk + merge de todos
os branches (trunk’)
• Requer times pequenos e experts
• Relativamente fácil no CVS e GIT mas bastante trabalhoso no SVN
• Requer avalanche de integrações. Criticado pelo Fowler http://bit.ly/bBjxbS

12. Branch por Time – Visão Geral
1. Descrição
• Detalhes em http://bit.ly/ctlRvc por Henrik Kniberg
• Testes unitários e de aceitação rodam em cada commit em cada branch / trunk
• Cada branch tem um owner que define as políticas
• Mainline (trunk/head) sempre estável para Release

13. Branch por Time – Pros e Cons
1. Pros
• Habilita times grandes a trabalharem em streams múltiplos.
• Mainline (head/trunk) sempre estável para release
• Habilita times pequenos em sub-áreas do sistema
• Menos branches do que Branch by Feature
2. Contras / Ressalvas / Dicas
• Todo merge em todo branch deveria ser trazido para todo outro branch imediatamente.
Merges diários (mas teoricamente não muito problemáticos)
• Instabilidade de trunk/mainline ainda existe, mas em “trunks de time”
• Cada branch precisa de um pipeline de deploy (build próprio etc)
• Não se pode dar merge de 1 mudança no trunk – tem que ser todo o branch
• Branches divergem mais rapidamente (muitas pessoas comitando)
• Merging mais complexo do que Branch por Feature.

14. Branch (quase) Nunca
1. Descrição
• Detalhes em Continuous Delivery, capítulo 14
• Ter um trunk e tentar esconder as features em tempo de execução, até estarem
prontas
• Modelo ok para times extremamente pequenos ou softwares bem pequenos, mas
inviável no nosso escopo, então não expandirei aqui
• Essência da filosofia: Branch = dor, evite a dor. Pelo menos minimize ao máximo.

15. Branch como Essência, Sempre
1. Descrição
• (Veja Diagrama maior no próximo slide)
• Utilizado em um sistema de controle de versão onde o conceito de branch é o cerne do
modelo
• Casa bem com Git, onde a metáfora é de grafo com nodos e arestas, e a pessoa pode
pegar/contribuir novas arestas&nodos nesse grafo
• Permite a integrantes combinarem partes de terceiros, escolherem o que entra e o que
não entra
• Permite um modelo misto dos anteriores, evitando overhead
• Popularizado com http://nvie.com/posts/a-successful-git-branching-model/
• Utilização de várias “pistas paralelas”, cada qual com um modelo: branch por features,
uma branch por release, etc. Veja imagem.

16. Branch como Essência, Sempre (imagem maior)

17. FIM. Piloto?
FIM. Vamos começar um piloto?