Best practices for using Git with Magento?

Question

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.

Answer 1

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/

Answer 2

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:

# 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:

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/

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.

Answer 3

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…

Answer 4

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:

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.

If your modification concerns PHP code:

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.

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.