Eu já vi ramos de desenvolvedores usados em dois cenários principais:
A comunidade de código aberto, na qual essas ramificações são, na verdade, bifurcações de repositório, para que os mantenedores do projeto possam bloquear o acesso ao repositório principal e exigir integração por meio de solicitações pull. Isso torna a vida mais difícil para os colaboradores, mas muito mais fácil para os mantenedores, o que obviamente é exatamente o ponto, e este é um modelo de muito sucesso no GitHub.
Equipes e organizações que não possuem integração contínua e um histórico de instabilidade em suas implantações, ou pior, instabilidade em suas construções. Essas equipes geralmente tentam usar as ramificações do desenvolvedor como uma maneira de proteger a estabilidade da linha principal, e o resultado é - geralmente - um longo e muito doloroso período de mesclagem antes do lançamento, seguido por um período de estabilização ainda mais longo e mais doloroso, que às vezes não acontece até depois do lançamento.
Eu não quero que isso seja divertido sobre por que você precisa de IC, mas é claro pela sua pergunta que você sabe que não está integrando suas alterações com frequência suficiente, portanto, na IMO não há sentido em discutir o assunto.
A menos que você esteja trabalhando em uma equipe distribuída geograficamente com a necessidade de "bloquear" as alterações de desenvolvedores externos, o modelo de filial por desenvolvedor realmente não faz muito sentido. Especialmente não faz sentido com o git, porque todo desenvolvedor já possui tecnicamente seu próprio repositório. A maioria das organizações deve se integrar com muita frequência - como várias vezes ao dia.
Atualmente, faço parte de um grupo de cerca de 35 colaboradores, divididos em 4 equipes separadas, a maioria das pessoas faz check-in pelo menos 2-3 vezes ao dia, outras 10-15 vezes; é incomum ver construções quebradas e extremamente raro para elas permanecerem quebradas por mais de alguns minutos. O Git manipula mesclagens com tanta facilidade na maioria das vezes que as ramificações remotas do desenvolvedor são uma sobrecarga desnecessária. Basta puxar, mesclar localmente e executar testes de confirmação antes de enviar, é simples.
Se você absolutamente deve adiar a integração, a fim de proteger a estabilidade do branch master, o modelo típico, comprovada é usar um ramo instável - às vezes chamado de um ramo de desenvolvimento , como descrito em um modelo ramificação Git sucesso . Se os desenvolvedores não puderem se unir a esse ramo com êxito (que só precisa ser construído , não executado sem falhas) pelo menos uma vez por dia, você tem um problema de qualidade / disciplina e não um problema de controle de revisão; encobrir isso usando ramificações de desenvolvedor não integradas apenas adia o problema e, ao fazer isso, torna as eventuais mesclagens muito mais dolorosas e instáveis do que realmente precisam ser.
Os ramos de recursos não são os piores, mas poucos projetos da OMI são realmente grandes o suficiente para justificá-los; se o seu projeto for muito grande (ou seja, toneladas de recursos sendo trabalhados ao mesmo tempo), você verá melhores resultados ao dividi-lo em componentes autônomos separados do que na documentação sobre o problema com o controle de origem.
Você pode ignorar esse conselho, se quiser, e muitas equipes o fazem, mas uma das razões pelas quais o modelo de ramificação vinculado acima é tão popular e bem-sucedido é que ele foi projetado para funcionar com integração contínua, não contra ele.