在具有许多子模块的项目中实现 git flow 的最佳方法是什么

Question

我们搭建了一个Asp.net核心微服务项目，将代码组织成一个超级项目和多个Git子模块（每个微服务就是一个子模块）。现在我们要开始使用 Git Flow 工作流。

初始化 gitflow 的最佳方法是什么？我们是否需要每个子模块有一个 git 流，或者我们应该在超级项目级别有一个全局 git 流？

谢谢！

Answer 1

像readium/readium-js-viewer（使用子模块）这样的项目考虑使用 git flow 并在问题 392 中进行了讨论。

使用 git flow 将涉及将每个命令分解为它们的 Git 等效项，用作：

git submodule foreach —recursive 'git checkout develop'

但是（在本文档中）：

但是，由于多种原因，此工作流程已证明有些问题。

• git-flow 工具（本质上是调用命令行 git 例程的 bash 脚本）有许多错误。
  最重要的是，如果合并或发布过程出现任何问题，bash 脚本只会默默地失败——看似有效，但实际上却没有，当事实并非如此时，通常会报告成功。
• 一般来说，Git 在子模块的使用方面有些脆弱。例如，如果子模块的结构发生变化（例如文件夹结构发生变化），则合并和新分支创建可能会失败，因为 git 不知道如何正确删除过时的分支片段。
  丢弃的碎片需要手动删除。
• 对于我们相对较小的项目（例如，与 Adob​​e 的 Creative Suite、Eclipse 和其他大型项目相比），git-flow 工作流程似乎有点过分。
  发布分支工作流的一般目的是测试和合并一个复杂的项目。如果发现问题，可以修复它们并将结果推回到开发阶段。
  在实践中，我们很少在 RC 分支中遇到足够严重的问题，需要就地解决和重新合并。相反，我们只是记录一个问题并计划在下一个版本中修复它。

因此，使用完整的 git-flow 工作流程——工具和工作流程本身——似乎并不适合 Readium。
因此，我们建议 Readium 采用类似于 git-flow 的工作流程，但经过简化以满足我们的需要

因此，可以使用git submodule foreach —recursive, ...来使用分支，但您可能希望保持上述分支工作流程尽可能简单。

或者，OP Nabil Kem在评论中添加：

我最终删除了子模块，因为它们产生的问题多于好处。