Git/Maven：如何处理具有公共父项目的定制项目

在我的公司，我们处理基于单一基本解决方案的定制项目。定制的解决方案是Maven项目，它的父级是基本解决方案，这是另一个Maven项目。所有定制项目和基本解决方案都是不同的Git项目

为了让您有更好的想法，基本解决方案（Git中的project CORE）可以定义报警的基本生命周期，然后由每个定制项目（比如Git中的project NYC和NJ）来实现处理此报警特定用例的代码

正如你们看到的，我有三个核心项目，纽约和新泽西。最后两个取决于第一个

我们的问题是，在为NYC或NJ开发时，我们可能会发现适用于CORE的bug或更改。因此，部分开发人员认为，我们对NYC和NJ的开发应该始终基于CORE的最后一个快照版本，如果我们必须发布NYC，我们首先将CORE发布到修复版本，然后发布NYC，指向该修复版本的CORE，然后我们将NYC和NJ的开发版本指向CORE的新快照。然而，对于其他开发人员，我们认为这是不正确的，NYC或NJ的开发应该基于CORE的具体版本。如果您必须发布NYC，您将创建CORE修复版本的一个分支，如果以后您必须为此版本的NYC对CORE进行调整，您将在发布时创建的这个分支中进行调整。否则，如果我们总是基于最新的快照，那么当您在发布版本之后必须为其中一个定制项目开发新功能时，您不确定最新版本的CORE中包含了什么，甚至您的解决方案项目也可能存在编译问题

正如您所看到的，我们正在与我们的定制项目的支持者进行一次大讨论，这些项目指向核心或固定项目的快照版本

---

我确信这种架构一定有一个标准的工作流程，但在做了一些研究之后，我找不到太多关于它的信息。如果您能与我分享您如何处理类似项目的利弊，或者您能给我指一些白皮书或书，描述管理此类混乱的标准化方法，我将不胜感激。

我非常了解这场讨论，有“最新版本始终是正确使用的版本”的观点，也有相反的观点“使用稳定版本，并定期手动更新”

我认为我们应该区分两种情况：

正常发展

修复已发布版本中的错误

---

让我首先讨论第二点：当你修复一个bug时，你应该从发布的版本开始（而不是从你目前正在处理的代码开始），无论是你的核心还是你的定制项目。你可能已经在Git中标记了发布，所以你可以签出你的核心和项目，并构建bug修复版本

在常规开发中，您有两种选择：

使用内核的快照版本，这意味着您没有手动更新工作，但您总是有风险因内核中的意外更改而中断项目

定期对最新版本进行手动更新需要更多的工作，但可以确保您确切地知道何时要小心（其他时间，您都知道自己得到了什么）。这更像是处理外部依赖项（log4j、apachecommons等等）

---

“修复错误时，应从发布的版本开始“。看起来很有希望，但我仍然不太了解整个工作流程。因此，一旦您修复了在发布版本之后标记的核心分支上的bug，在某个时候您仍然需要将该分支合并到开发分支中。你什么时候会这样做？立即或何时发布新版本的core？如果旧错误的修复仍然与最近的代码相关，请尽快（立即或直接在下一版本之后）在开发分支中集成错误修复。