git - 在单个存储库中使用许多自治插件文件夹构建 git 和工作流

Question

我意识到这是一个非常模糊的问题，但我的团队很难想出一个好的计划来解决我们的问题。无论如何，我们都不是 git 或工作流专家，过去我们已经遇到过这方面的问题。

具体来说，我们有这种情况：

插件代码位于同一个私有存储库的不同文件夹中（出于各种原因，我们不希望每个项目都有单独的存储库。）

所以存储库结构如下所示：

通常需要客户特定的补丁或增强功能，此外，我们通常必须支持给定客户的特定插件版本。

也就是说，我们需要一个有组织的结构和工作流程，它允许以下内容：

能够顺利地在单个插件上工作，而不会与人们对其他插件的提交发生冲突（例如，不需要在单独的插件中拉取更改以将更改推送到当前插件。）理想情况下，这将更加严格，以便 PluginA 的开发人员不能破坏 PluginB 中的任何内容。
- 最佳方法猜测： ???
能够使用客户特定的代码修补基本/核心插件代码；
- 最佳方法猜测：为每个客户创建一个新分支并从那里开始工作。
能够轻松获取最新的客户特定插件并对其进行修补（使用上游或其他方式）；
- 最佳方法猜测：检查客户分支并将其与 master 的发布标签合并。标签必须非常容易识别，例如 $plugin_name.$build_number
通过将二进制文件发布到中心位置（例如 Box）来自动发布构建的方式。
- 最佳方法猜测：以某种方式通过 post-commit 钩子实现这一点。
构建应自动增加其构建编号。我猜这对于 Maven 大师来说是一个单独的问题，但只是把它扔在那里。
- 最佳方法猜测： ???

我一直在研究子模块、gitslaves、标签、分支等，试图提出解决所有这些问题的结构和开发过程的建议。

请记住，这些开发人员中没有一个对 git 或版本控制非常有经验，而且我们没有系统管理员来处理此类工作……所以越简单越好。

对以上任何一个有意见吗？我想最重要的项目是第一个子弹。

score 1 · Accepted Answer

首先：如果插件是真正独立的项目（从某种意义上说，它们是独立版本、分支和发布的），那么您真的希望将它们放入单独的存储库中。例如，分支始终是每个 repo 的。

如果您觉得必须使用单个 repo：

能够在单个插件上顺利工作，而不会与人们对其他插件的提交发生冲突（例如，不需要在单独的插件中拉取更改以将更改推送到当前插件。）理想情况下，这将更加严格，这样 PluginA 的开发人员不能破坏 PluginB 中的任何内容。

我不认为会有问题。是的，你需要在推送之前拉取（这就是使用一个 repo 的结果），但是提交到其他项目不会引起冲突，所以没有害处。

能够使用客户特定的代码修补基本/核心插件代码；最佳方法猜测：为每个客户创建一个新分支并从那里开始工作。

是的，这里没有变化。只有分支将适用于所有项目的轻微烦恼；但是您可以对分支采用一些命名约定。

能够轻松获取最新的客户特定插件并对其进行修补（使用上游或其他方式）；最佳方法猜测：检查客户分支并将其与 master 的发布标签合并。标签必须非常容易识别，例如 $plugin_name.$build_number

是的。

通过将二进制文件发布到中心位置（例如 Box）来自动发布构建的方式。最佳方法猜测：以某种方式通过 post-commit 钩子实现这一点。

“最佳”取决于许多因素，但您很可能需要一个CI服务器，即构建守护程序。提交后挂钩也应该可以工作，但是您将需要相当多的基础设施来运行构建、存储日志等。如果您可以使用 CI 服务器，您真的不想自己这样做。

构建应自动增加其构建编号。我猜这对于 Maven 大师来说是一个单独的问题，但只是把它扔在那里。

这确实是一个单独的问题。问它作为一个。

1 回答 1