将 Git 与 Magento 结合使用的最佳实践？

Best practices for using Git with Magento?

提问by acorncom

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).

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

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:

我研究了 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

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?

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

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?

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

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?

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

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.

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

采纳答案by Johann Reinke

I think you can use modgit tool for this: https://github.com/jreinke/modgitYou'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/

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

回答by wik

Non of those methods you mention really worked for me...

你提到的那些方法都没有真正对我有用......

Currently I'm using pearto install and manage upgrades of core and community modules, and committing entire magento structure into the git repository with the following .gitignore file:

目前我正在使用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

and using the following shell command to keep empty directories:

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

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

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/

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

Update:

更新：

Magento Composer Installer- worth looking.

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

Composerbecoming standard dependency management tool for PHP, so, you'll get much more advantages utilizing it with in your project.

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

You won't need commit nor branch extensions, themes, libs into your project tree, but always have proper versions and dependencies.

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

Thanks.

谢谢。

回答by Greg Robbins

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.

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

I have about the same .gitignore file as you, so that looks good.

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

I did a writeup about how we use git as a team for managing magento stores here, maybe it will be useful to you:

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

Best practices for Magento Deployment

Magento 部署的最佳实践

回答by Nowhere man

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).

这正是之前使用 quilt 所做的，现在您使用Stacked Git（在 Git 之上）、Mercurial Queues（在 Hg 之上）或Loom（在 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.

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

Pure Git

纯 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.

以下内容认为您正在克隆 Magento Git 存储库。如果他们不使用 Git，您仍然可以通过首先将他们的历史转换为 Git 来完成，例如使用定制。

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.

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

You basically follow Quilt's workflow with normal Git tools.

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

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…

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

回答by Yauhen Yakimovich

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 strategieswhich I will recommend but I am not sure why do you need to merge at a first place.

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

Best practice of merging is to avoid it and Magento architecture is flexible enough to allow it. Follow a simple rule set:

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

1. Avoid patching the vendor code.
2. If you can't. Before doing a patch, consider packing your changes into a custom Magento module and placing it into app/code/local.

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

If your modification concerns PHP code:

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

1. You can benefit from OOP and minimize changes to a certain methods only. Extend respective classes.
2. Overwrite respective class using the Magento configuration mechanism in config.xml.
3. If previous is impossible to achieve - place your changes (patched classes) into app/code/local, i.e. higher in include_path order so that your code will be efficiently used instead of the vendor's code.

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

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.

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

If your modification concerns JS -> again, use layouts to link the code placed in js or skin folders.

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