É melhor mesclar "frequentemente" ou somente após a conclusão uma grande mesclagem de ramificações de recursos?

Digamos que várias ramificações estejam sendo desenvolvidas Ae B, assim como uma ramificação incremental de "correção de bugs" C.

Agora Cjá está "terminado" e mesclado no mestre. Ae Bainda estão em desenvolvimento e não serão corrigidos antes (talvez) de outro ramo de correção de erros ser mesclado no master.

É uma boa ideia mesclar o Cquanto antes nas ramificações dos novos recursos? Para que os novos recursos fiquem o mais próximo masterpossível? Ou é melhor deixar que o novo recurso seja desenvolvido em seu próprio "mundo", unindo-se ao mestre assim que terminar?

De qualquer forma, haverá conflitos, portanto é necessário gastar tempo em consertá-los.

Quanto mais tempo um ramo permanecer, mais ele poderá divergir do ramo principal e mais confusa e complicada será a mesclagem resultante quando finalmente terminar. Dez conflitos pequenos são mais fáceis de resolver do que um conflito maciço e podem realmente impedir que os desenvolvedores dupliquem ou desperdiçam esforços. Dado que, você deve se fundir masterem Ae Bregularmente; uma vez por dia é uma recomendação bastante comum, mas se você tiver muita atividade em suas filiais, poderá mesclar várias vezes ao dia.

Além de facilitar a resolução de conflitos, você menciona especificamente Cum ramo de correção de erros. Como desenvolvedor, eu gostaria que minha filial tivesse todas as correções mais recentes, para garantir que não estou repetindo o comportamento que levou a um bug ou escrevendo testes com base em dados errados.

De qualquer forma, haverá conflitos, portanto é necessário gastar tempo em consertá-los.

Se você sabe que haverá conflitos, talvez queira adotar uma estratégia de ramificação diferente. Mantenha várias alterações nos mesmos arquivos na mesma ramificação sempre que possível e reduza ou elimine o número de conflitos. Refatore as histórias para que elas sejam completamente independentes, tanto quanto possível, e refaça as ramificações para cobrir várias histórias (ramificação, recurso e história nem sempre são intercambiáveis).

Supondo que sua intenção seja eventualmente mesclar A, B de volta ao mestre e manter uma única base de código, nunca é uma boa idéia desviar-se do mestre demais. Desviar do master por muito tempo, especialmente quando correções de bugs e outros desenvolvimentos estão sendo mesclados para master, pois A, B está sendo desenvolvido, certamente causará conflitos.

Eu consideraria estratégias semelhantes às seguintes

1. Quem é responsável por A, B deve observar o mestre de perto e se fundir em quaisquer alterações.
2. Melhor ainda, se você possui automação de compilação e teste, certifique-se de que A, B sejam mescladas no mestre e passe nos testes todas as noites.
3. Com base no seu comentário a outra resposta, parece que A, B pode demorar um pouco para se desenvolver. Nesse caso, você pode até considerar que A, B se fundem também para que, no final, você não tenha grandes problemas para mesclar os dois novamente ao mestre.
4. Em um nível superior, pense por que você precisa de 2 linhas separadas de desenvolvimento longo. Você poderia dividir em fusões menores? Você poderia entrar em micro serviços separados?

Normalmente , muitas vezes é melhor do que um maciço.

Solicitações pull menores e mais frequentes são quase sempre melhores.

Comecei a usar sinalizadores de configuração principalmente para poder fazer solicitações pull menores mais cedo, para, por sua vez, mesclar o código com mais facilidade, mas deixar o recurso desativado. Quanto menor a solicitação pull, mais fácil é revisar o código, mesmo se houver mais solicitações pull totais. A maioria dos seres humanos de qualquer espécie não será capaz de fazer análises significativas de solicitações massivas de pull. É muito difícil para a RAM mental de alguém entender todas as implicações possíveis de uma mudança maciça de código.

Há uma sobrecarga extra na criação de um sinalizador de configuração, portanto, não vale a pena em recursos menores. Mas, de qualquer maneira, sua solicitação de recebimento será pequena.

Pode haver situações, no entanto, em que o recurso deve ser liberado de uma só vez. Mesmo assim, pode ser melhor fazer solicitações pull menores para outra ramificação feita para esse fim.

A maioria dos meus colegas geme quando alguém cria uma solicitação de recebimento massiva e, na maioria das vezes, com razão.

Observe também que, às vezes, eu preciso escolher os commits em ramos separados. Se o que precisa ser escolhido em cereja puder ser colocado em um único commit, será mais fácil movê-lo para outros ramos. Este é um caso em que, na verdade, ter poucos commits é melhor, mas não é exatamente o processo padrão se você está procurando.

Em Refatoração de Martin Fowler, o conselho que ele dá é nunca deixar que um ramo se ramifique do mestre por mais de um dia. IIRC, faça uma pequena alteração, teste para garantir que não quebrou nada e depois faça a mesclagem novamente.

Outra opção para alterações de longa duração que podem estar concluídas, mas ainda não prontas para uso, é colocá-las atrás de um sinalizador de recurso para que possam ser mescladas no mestre, mas sem o risco de quebrar nada. Então, quando estiverem prontos para serem usados, o sinalizador de recurso poderá ser removido.