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.