这是我的问题 - 我有一个代码库，必须部署到三个不同的环境。 90％的代码都很常见。另外10％是每个环境独有的。我想使用git-flow工作流程（master，develop），但我觉得我需要第二层“开发”分支（develop_a，develop_b，develop_c），这些分支从“develop”分支出来。如果我这样做，我可以在“develop”中进行常见的代码更改，然后定期将开发更改合并到develop_a，develop_b和develop_c中。与此同时，我可以在这些分支的分支上处理特定于develop_a，develop_b和develop_c的问题。
使用这种方法使得“主”分支从可以发布可释放软件的角度来看几乎没有意义。 develop_a，develop_b和develop_c是包含要为每个环境发布的完整软件的分支。我试图找出是否有一些建立的工作流程或最佳实践支持这一点。我不认为a，b，c的不同存储库是有意义的，因为大量的公共代码。
我认为更好/更长期的解决方案是以这样的方式重构代码，即创建支持develop_a，develop_b和develop_c的唯一性的接口和类，并且部署的版本（a，b，c）在运行时（还有其他问题和复杂因素可能导致这种情况不可能）。我相信我可以长期探索这种方法，但我也有短期需要建立工作流程，以便人们可以开始研究这些版本，以便我们可以在现场进行测试。不远的将来。
任何想法都将非常感激。
你的问题是使用submodule的理想场所。
git submodule add [url to common repo]。git submodule update更新。git submodule init，
git submodule update。然后，您将部署各个存储库。它们现在包含公共代码以及在可运行的混杂中的单独休息。因此，您可以使用您想要的任何分支方案。
除了使用git-flow方法之外，我不确定你需要做任何事情。
通过阅读您的帖子，我的印象是您有一些核心代码和一些特定于平台的代码，并且它们混合在一起（因为您提到重构以将它们分开）。
我还有这样的印象：特定于平台的代码位彼此正交 - 也就是说，平台A特有的代码对平台B等没有影响。
因此，在我看来，如果您让开发人员对核心代码进行更改，他们需要在所有平台上对其进行测试，以确保他们没有错误地使其特定于平台。因此，尽可能快地共享核心代码是一种胜利。
如果我的理解是正确的，请考虑只维护一个存储库，但在构建系统中设置三个不同的目标{platform-A，platform-B，platform-C}。这应该让您的开发人员在核心更改上相互合作，并允许您在任何提交时自动测试所有平台上的代码。
稍后，如果您将代码重构到可以分离A / B / C特定代码的位置，那么创建子模块可能是有意义的。但我仍然不明白为什么。更容易IMO只是创建子目录并保持每个人紧密合作的传统。