对于多个依赖项目，合适的版本控制/分支/开发流程是什么

如何解决对于多个依赖项目，合适的版本控制/分支/开发流程是什么

我们有以下场景：

由多个项目（模块）组装而成的产品 - 我们称之为前端（FE）、后端（BE）、其他（OT）
FE 使用 BE 作为 Web API，而 BE 通过另一个 API 集成到 OT。
独立的团队负责 FE、BE 和 OT，它们位于不同的代码库中，并具有独立的构建流程。
项目要求在不断发展，因此实际功能范围可能会随时发生变化。

假设我们有 2 个新的大型功能请求 - F1 和 F2。每个项目都会有一个团队并行处理每个功能——因此 FE/F1、BE/F1、OT/F1 团队将在 F1 上工作。由于 FE 依赖于 BE 而 BE 依赖于 OT，当所有项目的所有团队都同步，他们的代码经过验证和测试时，F1 可以被视为生产就绪。然后可以将每个项目上的 F1 部署到产品中。

到目前为止，我的问题是 - 在开发和部署功能时保持独立项目/模块同步的最佳策略是什么？ 我想出了以下方法：

功能开发从每个模块的最新生产状态（基本上是从 Master HEAD 分支出来）开始。因此，此时所有 F1 团队都在各自的 FE/F1、BE/F1、OT/F1 分支上工作。
QA/验证环境由最新的生产状态组装而成，其中功能开发提交被迭代推送、测试并修复错误，直到代码可以生产。
像 QA 一样创建一个临时环境，并在那里为 UAT 执行生产构建。
如果一切顺利，F1 分支会被压缩并部署到 Master 并重建生产环境。与此同时，FE/F2、BE/F2、OT/F2 团队正在开发各自独立的 QA 和 UAT 环境。

现在，我的第二个问题与第二个功能请求有关。 F1 功能已经部署在生产中，所以 F2 功能分支落后（它们是在创建 F1 分支的同时创建的）。

通常，如果单个开发人员使用小功能分支处理小功能，我会采用变基方法，因此我会将我的功能分支变基到 Master 的最新状态，将冲突修复到我的功能分支中，然后挤压/合并回 Master。

但是对于在同一个分支上工作的更大的团队，rebase 引入了很多潜在的大混乱，所以我的问题是：在将 F1 部署到 Dev 并且 F2 落后之后，这是否是最合适的方法只是将 Master 合并到 F1，根据最新的生产版本重建 F1 暂存和 QA 环境并重新验证、修复冲突等？

其他问题：

如果在开发功能（假设是 F1）期间，只需要部署其中的一部分怎么办？假设您正在构建一个包含 5 个信息块的用户配置文件页面，但在开发过程中，客户说要使用已经完成的 2 个块来部署页面？我的第一个想法是将功能分支分支到一个单独的分支 (F3)，创建一个单独的 QA/UAT 环境，将其部署到生产并按上述步骤进行，将功能分支和环境“更新”到最新的生产状态。
当两个独立的团队正在开发每个功能时，如何处理会出现（通过范围更改）在一个功能中并用于另一个功能的可重用代码？例如，如果您在 F1 团队中并且您的功能现在包含一个显示某些信息的用户配置文件块，而 F2 功能也使用该块？我的想法是，一旦一个团队这样做，它就会被精心挑选为另一个功能分支，经过测试、部署，其余的都是一样的。

顺便说一句，我知道在“完美世界”场景中，有一个可靠的产品定义过程，范围没有变化，功能很小，原子性且可立即部署，但这就是我正在尝试的情况来解决。

到目前为止，我们一直使用类似 gitflow 的流程，其中功能或部分功能被推送到开发分支和开发环境。不断地重建和测试。如果决定将某个功能或功能的一部分投入生产，它会被精心挑选到预生产分支和环境中，进行测试和部署。但这是一个非常不稳定的过程，我想摆脱它，因为从一堆其他提交中“提取”一个特性，特别是在处理数据迁移时是一个非常危险的策略和孤立的行为（并且从其他提交）可能会有很大不同。