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 n

Answer 1

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

Answer 2

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 3

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

Answer 5

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.