2

已经提出了与此类似的问题，尽管它们并不是我想要做的。

起初我以为我需要一个 git 子模块，然后设置一个超级项目，然后合并一个子树，但我不确定这些是否真的适合。

我有一个项目（Eva），我正在为它编写一些可选的扩展。因此，如果您要从 Github 下载 Eva 副本，它不会包含可选插件，但您可以单独获取并使用它们。

可选扩展与 Eva 位于相同的目录结构中。到目前为止很简单...

Eva
 |
 --- system/
 --- events/
   |
   --- core_events
 --- tests/
   |
   --- core_tests

Extension A
 |
 --- events/
   |
   --- [extension A]
 --- tests/
   |
   --- [extension A tests]

今晚我想为这些扩展添加测试，目前我将它们放在本地 Eva git repo 之外的单独目录中。为了运行这些测试，我真的需要这些扩展与 Eva 位于同一目录中，事件依赖于核心系统来运行。

Eva
 |
 --- system/
 --- events/
   |
   --- core_events
   --- [extension A]
   --- [extension B]
 --- tests/
   |
   --- core_tests
   --- [extension A tests]
   --- [extension B tests]

我可以将 Eva 项目文件复制到扩展 repo 目录中，但如果我修改 Eva 的源代码，那么我必须继续复制这些更改。

我应该继续这个笨拙的设置，还是有更优雅的方式 git 可以适应这个？

也许我的要求与其他问题相反。我的扩展是 Eva 的一个子项目，我需要偶尔从 Eva repo 中获取更新。

如果我在有人克隆 Eva 时将我的扩展存储库添加为子模块，他们也会获得所有可选插件吗？我不想要那个。

也不确定子树合并是否合适，我永远不必将扩展项目拉入核心 Eva 项目。

4

3 回答 3

3

我认为您最好的选择是尝试更改项目布局，使每个扩展更加独立，IE 驻留在它自己的目录中，例如 /extensions。

在框架启动/测试运行时，扫描该目录并动态加载扩展。这样，您不仅可以轻松开发和使用 git，而且还可以更轻松地使用各种打包选项、IE tarball。它使用户可以轻松查看使用了哪些扩展。

然后，您还可以允许 3d 方使用他们选择的 VCS 轻松开发“树外”扩展。

于 2011-02-19T21:00:46.527 回答
0

一个位于 hour 项目根目录的简单 shell 脚本怎么样，称为 plugin_manager，它允许用户列出已安装的插件、列出项目服务器上可用的插件以及下载和安装新插件？对于最终用户来说，这可能比争论 git 子模块更直观，特别是如果他们不熟悉 Git。

下载和运行测试可能只是用户运行时脚本执行的步骤之一 $ plugin-manager download foo-module

有关一个很好的示例模式，请查看The Drush (Drupal shell) commands的文档。

于 2011-02-10T00:06:55.343 回答
0

我认为这可以通过设置 git 挂钩来实现，这样每次提交（或推送）到核心或扩展存储库（单独保存）都会导致更新包含两者的最新副本的发布测试目录。由于缺乏VonC对此的了解，我只能将您重定向到例如手册页和git community book 的第 5 章。

事实上，更简单的解决方案是使用两个 repos ( cp -rs) 的软链接副本设置发布测试目录。不幸的是，在这种情况下，您必须记住在将新文件添加到任一存储库时添加新的软链接。

于 2011-02-18T10:54:29.537 回答