独立插件的子模块
我正在寻找一种组织项目存储库的方法。该项目是闭源的，但它包含一个我想公开的子文件夹。该文件夹包含从主项目调用的“插件”。所有这些插件都需要主项目存在，但当然主项目不需要它们才能工作。
通常的方法是使用插件的子模块，但我不太满意这对主项目意味着什么。由于主要开发与插件完全分开，我不想用插件子模块的更新弄乱它的历史，而且我实际上不希望插件成为主（核心）程序的一部分。
所以我更想要的是相反的情况，即主程序是插件存储库的子模块，以便主要开发完全独立于插件。问题是我的程序结构要求插件位于主目录树内部，以便可以正确访问它们。
对于子模块是“更大”或“外部”存储库的情况，是否有某种标准方法？或者您有其他想法来解决这个问题吗？
I’m looking for a way to organize my project’s repository. The project is closed source but it contains a single subfolder which I want to make publically available. That folder contains “plugins” that are called from the main project. All those plugins require that the main project is there, but of course the main project does not need them to work.
The usual approach would be to use a submodule for the plugins, but I’m not too happy with what this means to the main project. As the main development is completely separate from the plugins, I don’t want to mess up its history with updates from the plugins submodule, and I actually don’t want the plugins to be part of the main (core) program.
So what I rather want to have is the reverse situation where the main program is a submodule of the plugins repository so that the main development is completely independent from the plugins. The problem is that my program structure requires the plugins to be inside of the main directory tree, so that they can be accessed correctly.
Is there some standard approach to such a situation where the submodule is the “bigger” or “outer” repository? Or do you have another idea to solve this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
三个选项：
只需手动单独克隆插件存储库。将“plugins”目录添加到运行时存储库的 .gitignore 文件中，并在 README 中添加注释，详细说明插件存储库的位置以及如何克隆它。插件存储库可以随时通过简单的
cd 插件进行更新； git pull。如果您希望避免额外的步骤，您可以在本地主 git 存储库上添加一个 post-receive 挂钩来更新插件存储库，但这只会影响您的本地存储库。使用子模块。为了将最新的插件添加到运行时环境中，您必须进行提交以跟踪插件子模块的头部。例如 git add 插件； git commit -m“跟踪最新插件”。然后可以使用 git pull 完成更新/部署； git submodule update --init --recursive
使用子树。我认为这不是您想要的，但您可以在 Pro Git。更新插件需要多个步骤，这在生产中甚至可能无法完成。
如果您有某种自动构建系统，我会考虑使用子模块。否则我会选择 1，因为它的维护费用最少。
Three options:
Simply do a separate clone of the plugins repo manually. Add "plugins" directory to the runtime repo's .gitignore file and put a note in the README detailing the location of the plugins repo and how to clone it. Plugins repo can be updated at any time with a simple
cd plugins; git pull. You could add a post-receive hook on the main git repo locally to update the plugins repo if you wish to avoid extra steps, but this would only affect your local repo.Use a submodule. In order to get the latest plugins into your runtime environment you'd have to do commits to track the head of the plugins submodule. E.g.
git add plugins; git commit -m "tracking latest plugins". Updating/deploying could then be done withgit pull; git submodule update --init --recursiveUse a subtree. I don't think this is what you want, but you can read about it at Pro Git. Updating the plugins would require multiple steps which may not even be doable while in production.
If you have some sort of automated build system I'd consider a submodule. Otherwise I'd just go with 1 since it will have the least maintenance.