我意识到这是一个非常模糊的问题，但是我的团队在解决我们的问题时遇到了很多困难。我们都不是git或工作流程专家，我们过去已经遇到过这方面的问题。
具体来说，我们有这种情况：
插件代码驻留在同一个私有存储库中的不同文件夹中（由于各种原因，我们不希望每个项目都有一个单独的存储库。）
因此存储库结构如下所示：
通常需要特定于客户的补丁或增强功能，而且，我们经常需要为特定客户支持特定的插件版本。
也就是说，我们需要一个有组织的结构和工作流程，允许以下内容：
我一直在研究子模块，gitslaves，标签，分支等，试图提出一个结构和开发过程的建议来解决所有这些问题。
请记住，这些开发人员对git或版本控制一般都没有经验，我们没有系统管理员来处理这类工作......所以越简单越好。
对上述任何一方有何意见？我想最重要的项目是第一颗子弹。
答案 0 :(得分：1)
首先：如果插件是真正独立的项目（从某种意义上说它们是独立的版本，分支和发布），那么真的想要将它们放入单独的存储库中。例如，分支始终是每个回购。
如果您认为必须使用单个回购：
能够顺利地处理单个插件而不会发生冲突 来自人们提交到其他插件（例如，不需要提取更改 在一个单独的插件中将更改推送到当前插件。）理想情况下 这将更加严格，以至于PluginA的开发者不能 在PluginB中打破任何东西。
我不认为会有问题。是的，你需要在推送之前拉（这是使用一个回购产生的），但是提交到其他项目不会引起冲突，所以没有任何伤害。
能够使用客户特定代码修补基本/核心插件代码; 最好的方法猜测：为每个客户和工作创建一个新的分支 从那里。
是的，这里没有变化。只有分支机构对所有项目适用的轻微烦恼;但你可以为分支采用一些命名约定。
能够轻松获取最新的客户特定插件和补丁 他们（上游或其他）;最佳方法猜测：检查 out a customer branch并将其与master中的release标签合并。 标签必须是非常可识别的，比如 $ PLUGIN_NAME。$ BUILD_NUMBER
是
通过将二进制文件发布到a来自动发布版本的方法 中心位置（例如Box。）最佳方法猜测：以某种方式完成 这与post-commit hooks。
“最佳”取决于很多因素，但您很可能需要一个CI服务器即构建守护进程。 提交后挂钩也应该可以工作，但是你需要一些基础设施来运行构建，存储日志等。如果你可以使用CI服务器，你真的不想自己这样做。
构建应自动增加其构建号。我猜这是 对于Maven大师来说，这是一个单独的问题，但只是把它丢在那里。
这确实是一个单独的问题。把它当成一个。