3. Feature branches
•Devemos ter para cada funcionalidade
ou bug uma branch específica;
•O padrão de nomenclatura desta
branch deve seguir o padrão
FEATURE-[ID_TFS] ou BUG-[ID_TFS].
4. Develop branches
•Assim como temos em demandas
maiores (iframe Itau, Permissionamento
Sales, projeto SGRentals) temos que ter
uma branch que agrupe um conjunto de
features.
•O pull request deve ser feito para a
branch de desenvolvimento e não para a
master;
5. Release branches
•Uma release branch agrupa uma
entrega com um conjunto de melhorias,
funcionalidades e correções.
•Hoje não usamos em nossa cultura
mas poderíamos adotar para as
interações.
6. Hotfix branches
•É sugerido termos uma branch para os
hotfixes;
•Hoje, temos hotfixes sendo tratados e o
merge acontece diretamente com a
master sem intermediação de uma
branch.
7. Outros pontos
•Hoje, para cada build gerado no TFS ele já gera uma tag. Temos como recuperar o
projeto no tempo com uso disso pelo GIT.
–No próprio TFS temos uma retenção de 30 dias para os builds, ou seja, é possível fazer
deploy novamente sem ter que gerar novo build passado dentro deste prazo de retenção;
8. Pull Requests
•Processo onde uma solicitação de merge acontece entre uma branch e outra.
–Destaca as mudanças entre as branches;
–Possibilita o code review;
–Developer pode receber comentários;
–Developer pode fazer commits após solicitar o PR;
•Idealmente o pull request não dá conflito e, quando dá, temos que fazer rebase pra
HEAD da branch base;
•Já estamos usando há duas semanas com ganhos significativos no processo de code
review;
9. Nossa cultura de Pull Request
•Hoje já temos uma pequena parte da cultura implantada;
•Mudança: developer criar o pull request com responsável “Tester” e “Code Reviewer”
após encerrar o seu desenvolvimento; Se tiver conflitos, resolver.