类似于Quilt的工作流程

Question

我正在努力弄清楚如何在我自己的回购中为自定义代码最好地工作，同时与供应商的库（在这种情况下是Magento）集成。在我的情况下，我不需要将补丁推送到供应商（虽然这将是一个很大的附带好处）。

我查看了git子模块和git子树。我不认为git子模块可以满足我的需要。 Magento具有以下类型的树结构：

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

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

这让我失去了git子树。但是使用git子树，相同的核心假设（供应商分支，如名称所暗示的，一个子树）并不成立。 Magento不是一个子树，而是我的项目适合的核心库。这是对的吗？

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

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

Answer 1

你提到的那些方法并非真的对我有用......

目前我正在使用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 Installer - 值得一看。

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

您不需要在项目树中提交或分支扩展，主题，库，但始终具有适当的版本和依赖项。

感谢。

Answer 2

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

Answer 3

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

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

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

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

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

如果您的修改涉及phtml模板 - ＆gt;使用Magento布局机制替换供应商的phtml与您的。正确的设计定制无论如何都需要大量的修改活动和布局工作。

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

Answer 4

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

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

我和你一样有同样的.gitignore文件，所以看起来不错。

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

Best practices for Magento Deployment

Answer 5

类似于Quilt的工作流程

这正是以前用quilt做的事情，你现在使用Stacked Git（在Git之上），Mercurial Queues（在Hg之上）或Loom（在顶部） of Bazaar）。

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

Pure Git

以下考虑您正在克隆Magento Git仓库。如果他们不使用Git，你仍然可以先将他们的历史翻译成Git，例如使用tailor。

衍合

Git可以通过rebasing轻松地从不同的起点重新应用部分历史记录。因此，您也可以克隆Magento，处理您的代码，并在更新Magento时，从最后一个干净的Magento修订版开始，然后在新的干净的Magento修订版上重新定位。

你基本上使用普通的Git工具跟随Quilt的工作流程。

分行

另一种方法是简单地使用分支。你克隆Magento的repo，从中分支，做你的事，当你获取Magento的最新版本时，你合并了两个分支。它只是typical DVCS workflow，考虑到你是一个Magento开发人员，正在开发一个永远不会进入主分支的功能分支......

使用Git和Magento的最佳实践？

5 个答案:

更新

类似于Quilt的工作流程

Pure Git

衍合

分行