18

我正在研究如何在与供应商的库（在本例中为 Magento）集成的同时，最好地在我自己的存储库中为自定义代码工作。就我而言，我不需要向供应商推送补丁（尽管这将是一个很大的附带好处）。

我研究了 git submodule 和 git subtree。我认为 git submodule 不能满足我的需要。Magento 具有以下类型的树结构：

/app
  /code
     /community *
     /core
     /local *
  /design
     /adminhtml
     /frontend
        /base
        /yourtheme *
/lib
  /Zend
  /Varien
  /yourlib *
/js
  /yourjs *
  /varien
  /mage

使用 git submodule 似乎在单独的文件夹中效果最好（例如 / 是您的应用程序， /vendor/magento 是子模块）。但是，由于这种程度的交织，子模块似乎不是一个好的解决方案。我错了吗？

这给我留下了 git subtree。但是对于 git subtree，相同的核心假设（供应商分支，顾名思义，是一个子树）并不成立。Magento 不是子树，而是我的项目适合的核心库。那是对的吗？

如果这两种 git 方法不起作用，是否还有其他我应该知道的方法可以完成我想要完成的工作？

我不愿意追求的最后一个选择是拥有一个 repo，然后我只需将其应用于最新的供应商更改（从 tarball 中提取）。我不愿意追求这一点，因为我觉得拥有供应商的日志信息（从https://github.com/magentomirror/magento-mirror提取）对于整理新更新和找出哪些变化影响了我非常有帮助.

4

5 回答 5

3

我认为您可以为此使用 modgit 工具：https ://github.com/jreinke/modgit 您将能够使用 modgit clone 命令克隆一些 Magento 模块。此处提供了完整示例：http ://www.bubblecode.net/en/2012/02/06/install-magento-modules-with-modgit/

于 2012-03-01T21:45:49.400 回答
3

你提到的那些方法都不是真的对我有用......

目前我正在使用pear来安装和管理核心和社区模块的升级，并使用以下 .gitignore 文件将整个 magento 结构提交到 git 存储库中：

# Dynamic data that doesn't need to be in the repo
/var/*
/media/*
/downloader/pearlib/cache/*
/downloader/pearlib/download/*
/app/etc/use_cache.ser
local.xml

并使用以下 shell 命令保留空目录：

for i in $(find . -type d -regex ``./[^.].*'' -empty); do touch $i"/.gitignore"; done;

我想到的另一个想法是尝试一个供应商分支模型，但我担心它会增加额外的头痛，特别是在一些大型依赖树的情况下，即为了真正的效率，它必须在梨级别上集成，即每个下载的模块必须自动分支，因此，目前看来只与付费扩展一起使用似乎很好。

我试图在 magento 论坛上启动这个主题，但也没有得到任何回复： http: //www.magentocommerce.com/boards/viewthread/78976/

更新：

Magento Composer 安装程序- 值得一看。

Composer成为 PHP 的标准依赖管理工具，因此，在项目中使用它会获得更多优势。

您不需要将扩展​​、主题、库提交或分支到项目树中，但始终具有正确的版本和依赖项。

谢谢。

于 2011-03-10T06:32:19.990 回答
2

类似被子的工作流程

这正是以前使用被子所做的，现在您使用Stacked Git（在 Git 之上）、Mercurial Queues（在 Hg 之上）或Loom（在 Bazaar 之上）所做的。

这个想法是维护一系列相互堆叠的补丁，这些补丁适用于由 SCM 版本控制的文件（可能还会创建新文件，这就是您的情况）。在任何时候，您都可以完全弹出堆栈，更新上游代码，然后一一重新堆叠所有补丁。如果它们都干净地应用，它会自动完成，否则，该过程会在第一个错误补丁处停止。

纯 Git

以下假设您正在克隆 Magento Git 存储库。如果他们不使用 Git，您仍然可以通过首先将他们的历史翻译到 Git 来做到这一点，例如使用定制工具。

变基

Git 通过rebase可以很容易地从不同的起点重新应用历史的一部分。因此，您也可以克隆 Magento，运行您的代码，并在更新 Magento 时，从上一个干净的 Magento 修订版开始，然后将您的工作重新基于新的干净的 Magento 修订版。

您基本上可以使用普通的 Git 工具来遵循 Quilt 的工作流程。

分支机构

另一种方法是简单地使用分支。你克隆 Magento 的 repo，从它分支，做你的事情，当你获取 Magento 的最新版本时，你合并了两个分支。这只是典型的 DVCS 工作流程，考虑到您是一个 Magento 开发人员，在一个永远不会进入主分支的功能分支上工作……</p>

于 2011-07-21T08:27:06.337 回答
1

我认为你在谈论不同的事情。

Yauhen 的建议是完全正确的。您可以在 git 中完成所有这些，并且不需要子模块或子树。

我有和你差不多的 .gitignore 文件，所以看起来不错。

我写了一篇关于我们如何使用 git 作为一个团队来管理 magento 商店的文章，也许它会对你有用：

Magento 部署的最佳实践

于 2011-06-09T20:58:12.780 回答
1

您的问题更多是关于 git 的子模块与一般的子树。我想不出任何会影响比较的 Magento 细节。很可能您知道我会推荐的子树合并策略，但我不确定您为什么需要首先合并。

合并的最佳实践是避免它，并且 Magento 架构足够灵活以允许它。遵循一个简单的规则集：

  1. 避免修补供应商代码。
  2. 如果你不能。在打补丁之前，请考虑将您的更改打包到自定义 Magento 模块中，并将其放入 app/code/local。

如果您的修改涉及 PHP 代码：

  1. 您可以从 OOP 中受益，并尽量减少对某些方法的更改。扩展各自的类。
  2. 使用 config.xml 中的 Magento 配置机制覆盖相应的类。
  3. 如果以前不可能实现 - 将您的更改（已修补的类）放入 app/code/local，即在 include_path 顺序中更高，以便您的代码将被有效地使用，而不是供应商的代码。

如果您的修改涉及 phtml 模板 -> 使用 Magento 布局机制将供应商的 phtml 替换为您的。无论如何，适当的设计定制将需要大量的修改活动和布局工作。

如果您的修改再次涉及 JS ->，请使用布局链接放置在 js 或皮肤文件夹中的代码。

于 2011-01-23T20:06:03.187 回答