在我的公司，我们使用基于单一基本解决方案的定制项目。定制解决方案是Maven项目，它们是基本解决方案的父级，这是另一个Maven项目。所有，每个定制项目和基本解决方案都是不同的Git项目。
为了给你一个更好的想法，基本的解决方案（Git中的项目CORE）可以定义一个报警的基本生命周期，然后由每个自定义项目决定（让我们在Git中说项目NYC和NJ）实现处理此警报的特定用例的代码。
如你所见，我有三个项目CORE，NYC和NJ。最后两个取决于第一个。
我们的问题是，在为NYC或NJ开发时，我们可能会发现适用于CORE的错误或更改。因此，部分开发人员认为我们的NYC和NJ的开发应始终基于CORE的最后一个SNAPSHOT版本，如果我们必须发布NYC，我们首先将CORE发布到修复版本，然后我们发布纽约指向到这个修复版本的CORE，然后我们将NYC和NJ的开发版本指向CORE的新快照。但是，对于其他开发人员，我们认为这是不正确的，NYC或NJ的开发应该基于CORE的具体版本。如果你必须发布NYC，你可以创建CORE修订版的一个分支，如果以后你必须在这个版本的NYC上对CORE进行调整，你可以在发布时创建的这个分支中进行调整。否则，如果我们总是在最新的SNAPSHOT中，当您必须在发布后的某个定制项目中开发新功能时，您不确定最新版本的CORE中包含的内容甚至是您的解决方案项目可能存在编译问题。
如您所见，我们正在与支持者进行大量讨论，我们的定制项目指向SNAPSHOT版本的CORE或固定版本。
我确信这种架构必须有一个标准的工作流程，但经过一些研究后我无法找到它。如果你能分享你如何处理类似的项目，利弊，或者如果你能指出一些描述管理这种混乱的标准化方法的白皮书或书籍，我将不胜感激。
答案 0 :(得分：0)
我非常了解这个讨论，意见和＃34;最新版本总是使用正确的版本＆＃34;和反对意见＆＃34;采取稳定版本并定期手动更新＃34;。
我认为我们应该区分两种情况：
让我先讨论第二点：当您修复错误时，您应该从已发布的版本开始（而不是从您目前正在处理的代码开始），包括核心和自定义项目。您可能已经在Git中标记了这些版本，因此您可以检查您的核心和项目并构建错误修复版本。
在常规开发中，您有两种选择：