それに関する同様の質問を読んだことがありますが、それでも質問する必要があると感じています。承認待ちの小さな「機能」がたくさんあるシナリオがあります。私は一般的に2つのアプローチを見ています。
1.幹をしっかりと保ち、小さな「機能」ごとにたくさんの枝を用意します。基本的に、すべての新しいものはブランチです。
短所:
- どんなに小さな変更であっても、非常に多くのブランチをサポートすることは悪夢になる可能性があります。すべてのブランチの同期などを維持するなど
- これで見られる最悪の欠点は、承認する変更を簡単に調べることができるようにテストシステムをセットアップすることです (基本的に、非常識に見えるすべてのブランチをサポートする必要があります)。
長所:
- ブランチをトランクにマージし、新しいリリースをタグ付けして展開することが承認されると、一見簡単に見えます。
2.大きな機能の場合はブランチがリリースされ、小さな変更の場合はすべてトランク (比較的安定) に直接移動します。
長所:
- ほとんどの場合、すべてが直接表示されるため、テスト システムの設定が簡単です。大きな機能の場合、テスト時に別のブランチを簡単に維持できるはずです。
短所:
- リリースがどうなるかはよくわかりません。基本的にトランクの一部をリリースすることはできません。これには、クレイジーなチェリーピッキングが含まれます。他のアプローチは、新しいタスクを与える前に展開できるように、しばらくしてから (1 週間程度) すべての小さな機能を承認する必要があることを強制することです。リリース ブランチを作成しただけで、すべての小さな機能が公開されるか、まったく公開されません。これは、トップの人々との楽しいディスカッションになります。
保留中の小さなものがたくさんあると、技術的にフォローするのが非常に問題になると思います。