Feature Branching is a poor man’s modular architecture, instead of building systems with the ability to easy swap in and out features at runtime/deploytime they couple themselves to the source control providing this mechanism through manual merging. daqui
Feature Branching, ou branching por funcionalidade, é uma técnica muito usada para controle de versão de código em que um branch é criado para cada funcionalidade do sistema. A técnica facilita o controle do que será disponibilizado na versão a ser fechada: é feito o merge para o trunk somente das funcionalidades desejadas.
Martin Fowler explica no artigo Feature Branch porque evitar branches por funcionalidade é uma boa prática para quem faz Integração Contínua. Mesmo com sistemas de controle de versão mais modernos (e distribuídos) como Git, que é ótimo para fazer merges, usar branches por funcionalidade não é uma boa idéia.
No meu projeto atual, resolvemos evitar branches por funcionalidade. No caso de uma funcionalidade ficar pela metade em uma iteração, apenas removíamos os resquícios dela da tela (em geral, tirando do menu). Em alguns casos, foi preciso atrasar ou abortar a iteração, mas apenas em casos muito pontuais (mudanças críticas que afetavam o sistema como um todo).
Apesar da pontualidade desses casos, isso afetou negativamente o comportamento da equipe. Ser responsável por atrasar ou abortar uma iteração era algo muito ruim porque afetava negativamente o andamento do projeto. Por isso, eu e os meus colegas passamos a criar Feature Branches locais: deixámos de comitar o código frequentemente, afim de evitar comitar funcionalidades pela metade, que poderiam atrasar o entregável.
Esses feature branches locais fizeram que não houvesse integração contínua: só no final de cada funcionalidade a equipe comitava o código. Como, em geral, isso acontecia simultaneamente para várias funcionalidade e no final da iteração, isso acabava acarretando em mais atrasos nas entregas.
Logo percebemos isso e nos policiamos para que isso não ocorresse novamente.
Enfim, evite feature branches locais!
______
Outra prática ruim é trabalhar durante muito tempo com os testes no vermelho. Acontece quando você trabalha numa funcionalidade que faz testes em outros pontos do sistema falharem. Aí, você continua trabalhando na sua funcionalidade, ignorando os testes que estão falhando. Nesse caso, estamos dando passos muito longos e sem segurança. É importante seguir a regra de não inserir código de produção com testes falhando.
______
Há algumas equipes que prezam código limpo, mas que dão um tiro no pé: não comitam o código antes de atingir uma versão “perfeita”. É o over-refactoring.
______
Quem faz deploy contínuo tende a usar feature branches, mas cuidam para que eles existam pelo menor período de tempo possível.
Mente de Iniciante 