我目前正在试图找出，如何在一个场景中使用git flow进行发布管理，我有一个git存储库，其中包含两个解决方案中的大约15个项目以及数据库的脚本。
每个解决方案基本上包含一个将产生可执行文件的项目，以及包含DAL，SAP访问包装等两个解决方案所使用的基本功能的10个以上项目。 解决方案一是用户的UI应用程序 解决方案二是Windows服务 两个解决方案和数据库的发布不同步。这意味着通常只有三分之二的矿石被释放。这导致不同的版本号。例如，UI很频繁地发布，服务很少发布。数据库介于两者之间。因此，UI可以具有2.1.15版本，服务2.1.1和数据库2.1.5。
现在，如何处理共享项目？他们应该使用UI的版本号还是服务的版本号？
我如何解释其中一个共享项目的更改不会自动触发两个解决方案的发布？这意味着同时，生产环境包含相同项目的两个不同版本。这在某种程度上需要反映在存储库中。
我在这里有点失落，任何建议，经验等都会受到赞赏 我可以自由地以任何方式构建存储库和代码库，如果有帮助，我可以创建其他存储库。
答案 0 :(得分：3)
首先，如果你有不同的（尽管有点依赖）项目，这些项目不同，它们有不同的版本，那么一定要将它们放在不同的git存储库中。
如果您将所有产品都放在同一个存储库中，那么您的效率就会很低。例如，如果您正在使用UI而另一个正在处理该服务并对UI进行了一些小修复，那么当您将工作与它们合并时，您也可以更改服务（您不关心它）对）。
在15个项目中，如果某些项目关联得太紧密，您可以将它们保存在同一个存储库中（例如UI的组件）。
现在您拥有不同的存储库，您可以轻松地为它们管理单独的版本并分离版本号。
但是要注意的一件事是兼容性。例如，版本为2.4.5的UI可能与2.1.7-2.2.9版本的服务兼容，同样，2.1.10版本的服务可能与版本在2.4范围内的UI兼容。 .3-2.4.8。然后，每个版本的软件组件都应该能够检查其他组件的版本是否兼容。