Trunk-based development vs feature-branch
Com a engenharia de software evoluindo rapidamente nos últimos anos temos nos deparado com o desafio de manter softwares cada vez mais complexos, com equipes não tão enxutas em alguns casos e com mudanças acontecendo o tempo inteiro vem a questão: como mantermos nossos softwares atualizados e íntegros em meio a tantas mudanças?
Hoje em dia temos o git para realizar essa tarefa, mas em um período não tão distante as coisas não eram tão práticas como hoje, quem não se lembra do CVS, Mercurial, SVN, TFS, entre outros.
A partir do controle de versão acabam surgindo outras dúvidas, uma das mais frequentes é: qual estratégia de versionamento escolher? Eis que chegamos nas duas versões mais usadas que dão o título desse artigo: trunk-based development e feature-branch. Então vamos conhecer um pouco mais sobre essas formas abaixo.
Trunk-based development
Resumindo da forma mais simples possível: é a prática de fazer commits sempre na master/main e não utilizar branches para manter o desenvolvimento parcial. Cada commit é uma integração com o código final.
Feature-branch
Talvez esse seja o modelo mais usado por times atualmente.
Get Yan Soares’s stories in your inbox
Join Medium for free to get updates from this writer.
É a prática de criar um branch para cada feature. Só é feito o merge do código na master/main quando a feature está completa, eliminando a possibilidade de código não usado/não terminado ser mergeado com a master. A definição de feature depende do time, mas geralmente se refere a uma User/Tech Story. Rebases constantes com a master são importantes.
Qual modelo utilizar?
Não há uma resposta certa/errada e uma não necessariamente elimina a outra, há vários fatores para considerar e vou citar alguns: maturidade e tamanho do time, complexidade do projeto, se o projeto utiliza uma codebase compartilhada com outros times. São só alguns pontos de vários outros que podem surgir, tudo precisa ser bem analisado e discutido.
