A verdade é que não existe bala de prata. Usar feature flag é um jeito de aliviar a pressão sobre o tamanho de um PR.
Isso porque quanto maior é a distância de uma branch da main/master, maior se torna o risco de conflito e quebrar o projeto.
Imagine que você possui um sistema de grids simples, com filtro de busca, ordenação etc que a vida inteira listou os registros de um sistema e agora surge uma branch de Feature Request que transformará agora a visão em uma árvore com sistema de pastas que permite agrupar recursivamente os registros.
Haverá tarefas bastante extensas tanto no frontend como backend, a depender da equipe serão vários sprints até implementar algo desse porte. A solução que eu utilizo é introduzir PRs pequenos que não quebram o master o mais rápido possível, por ex, haverá momentos aonde você terá uma rota validada que não possui UI que consome nada e vice versa.
Então quando as equipes terminam suas tarefas, mas a FEATURE (milestone) não é atingido uma "feature flag" que pode ser diretivas #ifdef e #ifndef (C/C++), ou uma constante que vem de um arquivo de configuração qualquer que LIGA/DESLIGA a feature.
Isso torna mais fácil, por exemplo, ter um ambiente staging aonde a equipe pode flagar o que quer testar, ligando e desligando as features, posteriormente quando todas as tarefas são fechadas e o milestone da feature é atingido, remove-se as feature flags do código e sobe pra produção.
Assim cada branch vira uma micro PR que derivou da issue de feature inicial ex:
- [master]
^
- [release] tagueia versao
^
- [develop]
^
- [feature]
- [1204-feature-request-directory-system]
- [1205-tree-view-ui-refactoring]
- [1207-folder-thumbnail-generation]
- [1208-recursive-search]
- [1209-folder-drag-n-drop]
- [1210-folder-move-dialog]
- ...
- [1206-api-for-directory-routes]
- [1211-recursive-delete]
- [1212-recursive-search]
- [1213-move-file]
- [1214-move-folder]
- ...
Suponhamos que uma equipe de front e backend está trabalhando agora na "1204-feature-request-directory-system", seus PR serão derivados dessa branch e o mais rapido possível mergeados para branch develop, depois release e mesmo que incompleta o restante da feature, se ela não quebrar nos testes de integração, já faz merge pra master com a feature flag "1204-feature-request-directory-system" desligada.
Assim, a cada ciclo de sprint, as novas equipes que puxarem branch deveridas terão uma distância muito menor de alterações entre elas. No jeito "convencional" a master demoraria muito maias pra receber essas alterações porque a realease precisaria estar completamente finalizada no recebimento das features, bugfix etc e assim a cascata de PR sobe muito mais rápido pra produção.
E pra quem não quer trabalhar com as branchs intermediárias e trabalha em equipes também é igualmente benéfico. Eu acredito que o custo da organização é infinitamente menor que o da desorganização.