Ramos de recursos – não os use com o Git. Aqui está o porquê:
O objetivo da ramificação é isolar as mudanças umas das outras. Isso parece ser o oposto de CI – que deseja construir e testar cada mudança tão frequente quanto humanamente possível. Desenvolver em ramos separados quebrará o ciclo de feedback de testar todas as mudanças mais recentes juntas para saber quando algo quebra.
Testar com branches de recursos pode ser desagradável. Mesmo se você estiver fazendo testes contínuos em seu branch de recursos e outro desenvolvedor estiver fazendo testes contínuos em seu branch de recursos, eles não estão sendo testados juntos – então isso não é CI. Você poderia mesclar vários ramos de recursos à linha principal no final de um sprint e o caos se instalaria. Você pode ver problemas que foram introduzidos em qualquer ponto da vida dessas ramificações de recursos e pode ser muito complexo para diagnosticar e corrigir. Este é o problema que o CI foi projetado para eliminar em primeiro lugar! 🙂
Agora, talvez você tratasse o branch de recurso de forma que as alterações fossem mescladas no branch da linha principal todos os dias … nesse caso, eu diria que não é realmente um branch de recurso, então por que chamá-lo assim?
- Alguns defenderão os branches de recursos como melhores porque você pode fazer check-in com ainda mais frequência sem quebrar a compilação para todos. Mas em um sistema distribuído como o Git … isso não é realmente um problema. Você está trabalhando localmente em sua cópia do branch e fazendo compilações, então você saberá se compilou antes de mesclar com a linha principal. Este argumento cai por terra para mim. 🙂