将 Git 与 Magento 结合使用的最佳实践？
我正在努力弄清楚如何在我自己的存储库中最好地工作自定义代码，同时与供应商的库（在本例中为 Magento）集成。就我而言，我不需要向供应商推送补丁（尽管这将是一个很大的附带好处）。
我研究了 git 子模块和 git 子树。我认为 git 子模块不能满足我的需要。 Magento 具有以下类型的树结构：
/app
/code
/community *
/core
/local *
/design
/adminhtml
/frontend
/base
/yourtheme *
/lib
/Zend
/Varien
/yourlib *
/js
/yourjs *
/varien
/mage
使用 git 子模块似乎在单独的文件夹中效果最好（例如 / 是您的应用程序，/vendor/magento 是子模块）。然而，由于这种程度的交织，子模块似乎并不是一个好的解决方案。我这件事有错吗？
这给我留下了 git 子树。但对于 git 子树，相同的核心假设（供应商分支，正如其名称所暗示的那样，是一个子树）并不成立。 Magento 不是子树，而是我的项目所适合的核心库。这是正确的吗？
如果这两种 git 方法不起作用，是否还有其他我应该知道的方法可以实现我想要完成的任务？
我不愿意追求的最后一个选择是拥有一个存储库，然后我将其应用于最新的供应商更改（从 tarball 中提取）。我不愿意追求这个，因为我觉得拥有供应商的日志信息（从 https://github .com/magentorror/magento-mirror）对于整理新更新并找出哪些变化对我产生了影响将非常有帮助。
I'm working at figuring out how to best work within my own repo for custom code while integrating with a vendor's library (in this case Magento). In my case, I will not need to push up patches to the vendor (although that would be a great side benefit).
I've looked into git submodule and git subtree. I don't think git submodule will work for what I need. Magento has the following type of tree structure:
/app
/code
/community *
/core
/local *
/design
/adminhtml
/frontend
/base
/yourtheme *
/lib
/Zend
/Varien
/yourlib *
/js
/yourjs *
/varien
/mage
Using git submodule seems to work best in separate folders (e.g. / is your app and /vendor/magento is the submodule). However, with this degree of intertwining, a submodule doesn't seem like a good solution. Am I wrong about this?
That leaves me with git subtree. But with git subtree, the same core assumption (that the vendor branch is, as implied by the name, a subtree) doesn't hold true. Magento isn't a subtree, but the core library that my project fits within. Is that correct?
If those two methods of git don't work, are there other ones I should know about that would do what I'm trying to accomplish?
The final option I'm reluctant to pursue is having a repo that I then just apply over the latest vendor changes (pulled in from a tarball). I'm reluctant to pursue this as I feel that having the vendor's log information (pulled from https://github.com/magentomirror/magento-mirror) would be greatly helpful in sorting through new updates and figuring out what changes have affected me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为你可以使用 modgit 工具来实现此目的： https://github.com/jreinke/modgit
您将能够使用 modgit clone 命令克隆一些 Magento 模块。完整示例如下： http:// /www.bubblecode.net/en/2012/02/06/install-magento-modules-with-modgit/
I think you can use modgit tool for this: https://github.com/jreinke/modgit
You'll be able to clone some Magento modules with modgit clone command. A full example is available here: http://www.bubblecode.net/en/2012/02/06/install-magento-modules-with-modgit/
你提到的那些方法都不适合我......
目前我正在使用 pear 安装和管理核心和社区模块的升级，并使用以下 .gitignore 文件将整个 magento 结构提交到 git 存储库中：
并使用以下 shell 命令保留空目录：
我想到的另一个想法是给出尝试使用供应商分支模型，但我担心它会增加额外的头痛，特别是在一些大型依赖树的情况下，即为了真正的效率，它必须在梨级别集成，即每个下载的模块必须自动分支，所以，目前看来仅与付费扩展一起使用似乎不错。
我试图在magento论坛上发起这个话题，但也没有得到任何回复：
http://www.magentocommerce.com/boards/viewthread/78976/
更新：
Magento Composer 安装程序 - 值得一看。
Composer 成为 PHP 的标准依赖管理工具，因此，在项目中使用它您将获得更多优势。
您不需要将扩展、主题、库提交或分支到项目树中，但始终拥有正确的版本和依赖项。
谢谢。
Non of those methods you mention really worked for me...
Currently I'm using pear to install and manage upgrades of core and community modules, and committing entire magento structure into the git repository with the following .gitignore file:
and using the following shell command to keep empty directories:
Another idea I thought about it's to give a try a vendor branching model, but I'm afraid it will add extra headache especially in case of some large dependency trees, i.e. for the real efficiency it's must be integrated on the pear level, i.e. every downloaded module must be branched automatically, so, for now it's seems good to use with paid extensions only.
I was tried to fire up the subject on magento forum, but also didn't got any replies:
http://www.magentocommerce.com/boards/viewthread/78976/
Update:
Magento Composer Installer - worth looking.
Composer becoming standard dependency management tool for PHP, so, you'll get much more advantages utilizing it with in your project.
You won't need commit nor branch extensions, themes, libs into your project tree, but always have proper versions and dependencies.
Thanks.
类似 Quilt 的工作流程
这正是以前使用 quilt 所做的事情，现在使用 Stacked Git （在 Git 之上）、Mercurial 队列（在 Hg 之上）或 Loom（位于 Bazaar 之上）。
这个想法是维护一系列彼此堆叠的补丁，这些补丁适用于 SCM 版本化的文件（也可能创建新文件，这对您来说就是这种情况）。您可以随时完全弹出堆栈，更新上游代码，然后一一重新堆栈所有补丁。如果它们全部应用干净，则会自动完成，否则，该过程将在第一个错误补丁处停止。
纯 Git
以下内容认为您正在克隆 Magento Git 存储库。如果他们不使用 Git，您仍然可以通过首先将其历史记录转换为 Git 来完成此操作，例如使用 tailor.
Rebase
Git 可以轻松地从不同的起点重新应用历史记录的一部分，通过 变基。因此，您也可以克隆 Magento，工作您的代码，并且在更新 Magento 时，从上一个干净的 Magento 修订版开始执行此操作，然后在新的干净的 Magento 修订版上重新调整您的工作。
您基本上可以使用普通的 Git 工具来遵循 Quilt 的工作流程。
分支
另一种方法是简单地使用分支。您克隆 Magento 的存储库，从中创建分支，做您的事情，当您获取 Magento 的最新修订版时，您可以合并两个分支。这只是典型的 DVCS 工作流程，考虑到您是 Magento 开发人员一个永远不会进入主分支的功能分支......
Quilt-like workflow
This is exactly what was previously done with quilt, that you nowadays do with Stacked Git (on top of Git), Mercurial Queues (on top of Hg) or Loom (on top of Bazaar).
The idea is to maintain a series of patches stacked on one another, that applies to the files versioned by the SCM (potentially also creating new files, which would be the case for you). At any time, you can pop the stack entirely, update the upstream code, then restack all your patches one by one. If they all apply cleanly, it is done automatically, if not, the process stops at the first faulty patch.
Pure Git
The following considers you are cloning a Magento Git repo. If they don't use Git, you can still do it by first translating their history to Git, for example with tailor.
Rebase
Git makes it easy to re-apply a part of the history from a different starting point, by rebasing. So you could also just clone Magento, work your code and, when updating Magento, doing it from the last clean Magento revision and then rebasing your work on the new clean Magento revision.
You basically follow Quilt's workflow with normal Git tools.
Branches
Yet another way of doing it would be to simply use branches. You clone Magento's repo, branch from it, do your thing, and when you fetch Magento's latest revisions, you merge the two branches. It's just typical DVCS workflow, considering you as a Magento developper working on a feature branch that will never make it to the main branch…
一般来说，你的问题更多是关于 git 的子模块与子树。我想不出任何 Magento 细节会影响比较。您很可能知道 子树合并策略 我会推荐它，但我不确定为什么你需要首先合并。
合并的最佳实践是避免它，Magento 架构足够灵活，允许它。遵循简单的规则集：
如果您的修改涉及 PHP 代码：
如果您的修改涉及 phtml 模板 ->使用 Magento 布局机制将供应商的 phtml 替换为您的。无论如何，正确的设计定制将需要大量的修改活动和布局工作。
如果你的修改涉及JS ->再次，使用布局链接放置在 js 或皮肤文件夹中的代码。
Your question is more about git's submodule vs. subtree in general. I can't think of any Magento specifics that will influence the comparison. Most probably you are aware of subtree merging strategies which I will recommend but I am not sure why do you need to merge at a first place.
Best practice of merging is to avoid it and Magento architecture is flexible enough to allow it. Follow a simple rule set:
If your modification concerns PHP code:
If your modification concerns phtml templating -> use Magento layout mechanism to replace vendor's phtml with yours. A proper design customization will require heavy modification activities and layout work anyway.
If your modification concerns JS -> again, use layouts to link the code placed in js or skin folders.
我认为你在谈论不同的事情。
Yauhen的建议是完全正确的。您可以在 git 中完成所有这些，并且不需要子模块或子树。
我有和你差不多的 .gitignore 文件，所以看起来不错。
我在这里写了一篇关于我们如何使用 git 作为团队来管理 magento 商店的文章，也许对您有用：
Magento 部署的最佳实践
I think you are talking about different things.
Yauhen's suggestions are totally correct. You can accomplish all of this in git, and you don't need submodules or subtrees.
I have about the same .gitignore file as you, so that looks good.
I did a writeup about how we use git as a team for managing magento stores here, maybe it will be useful to you:
Best practices for Magento Deployment