我刚刚将一个大型 svn 存储库迁移到 git 并开始使用 gitflow。它就像一个魅力，但现在我正在考虑将那个大 repo 分成许多较小的 repo 。
假设repo目录树如下:
/repo
- libs
- apps
-- app 1
-- app 2
我们想将它分成三个存储库，一个包含核心结构(libs 和 apps 目录)，另外两个包含 apps 目录。
如果我使用 git subtree 像这样拆分，我将能够在每个部分单独使用 git flow 还是必须全局使用它？
PS:这是我在 stackoverflow 中的第一个问题，请多多关照 :)
最佳答案
我不使用 git flow，但我认为答案取决于您的模块化程度。不部署app1和app2能部署核心结构吗？你能独立部署 app1 和 app2 吗？您的开发团队是否足够庞大和成熟，可以将它们视为独立的工作流程？
如果这些问题的答案是"is"，我会主张将它们视为多个项目，每个项目都有一个独特的流程。但是，如果对其中任何一个的回答是“否”，我会避免破坏您的项目。事实上，如果大多数时候对 app1 和 app2 的更改也需要对核心存储库进行更改，我会完全避免破坏您的存储库。
嵌套存储库，无论它们是使用子树、子模块还是(上帝禁止)根据定义仅使用 .gitignore 来执行，都会使工作流程更加复杂。 git bisect 和 git log 这样的命令变得没那么有用了；跟踪历史和错误变得更加困难。新开发人员必须多学习一点才能开始编码。个人经验:小心走这条路。如果你的子 repo 协议(protocol)严重交织在一起，你将在一年后回到这里，为其他想要破坏他们项目的人写这个答案，比如一个有问题的 git 版本的 Pay It Forward。
关于git - 将 git flow 与 git 子树一起使用，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11991088/