Take the 2-minute tour ×

I've been coding Magento sites using cron jobs to handle backups but it gets a little clunky when trying to revert back to previous versions of the site. I essentially have to dig through the backups and manually revert things back. I've read up on git and I like the idea of being able to document my changes through the development cycle and revert back to just the specific things I change with a few commands.

Currently I have two branches in my local repo (master, develop). I essentially do all my development in the develop branch and merge everything over to the master branch when I'm done with a specific set of tasks and push things up to my gitbucket repo for backup purposes and just to get into the habbit of using a remote repo.

I'm new to git so does this sound sufficient for my scenario or can anyone recommend a good workflow process for a one man shop using git with Magento? Thanks.

share|improve this question
add comment

1 Answer

up vote 8 down vote accepted

We use the GitFlow model for our Magento development. It's similar to yours but with an extra branch for a staging site. Larger development tasks/fixes are also completed in separate branches to ensure develop is always reasonably stable. Our staging sites are a git repo with the staging branch checked out and production sites have the master branch checked out. When we're ready to deploy changes to staging we merge them to staging on our local machines, and push to a central git repo, then pull on the server. Works well, but you need to be careful of app/etc/local.xml as this should be different in each environment. You'll also want to make sure things like media and var folders do not end up in your git repo.

Github publishes a .gitignore for Magento, but the issue I have with it is that it excludes all of the Magento core files. You end up with a nice clean repository that contains only your changes, but not something that's deployable. We use a much simpler .gitignore which basically just excludes media var and app/etc/local.xml. We generally use a single remote (e.g. Github) and deploy from there.

On the servers we're deploying to, we generally have shell access and git installed so deployment is a matter of ssh'ing in and running a git pull (or fetch & merge) from the normal remote.

We maintain staging sites as a separate branch in git, and deploy them the same way. So our process looks like Develop in feature branch and merge into "develop" when done. When integration testing is complete, merge "develop" (or cherry-pick changes) to "staging" and deploy. When ready for production merge "staging" (or cherry-pick individual changes) to the "master" branch. This is basically GitFlow but out "preparation for release" branch is long lived.

As the Sonassi tutorial linked in the comments points out, the issue with symlinking media is that if you delete a media file from production you get a broken link in staging and vice versa. Instead of linking the two, we update staging code from git, but otherwise run the staging and production sites separately. If we need fresh data in staging, for any reason we'll take a copy of the production media and database and restore it to the staging site.

The Gitflow model uses version numbers for release tags, if you have version numbers which the team agrees on for releases, use them. Otherwise, if you have some sort of milestone plan, or sprint system you're working to and can identify a release that way, that would work also. If all else fails we use the date/time the deployment occurred. e.g.

git tag -a deployed-`date +%Y%m%d-%H%M` -m "Code release at `date`"
share|improve this answer
Thanks for the feedback. I've been using this .gitignore file github.com/github/gitignore/blob/master/Magento.gitignore Maybe I'll implement a staging branch as well. Do you have a seperate server setup as a remote that you push to when you're ready to test on that branch? Also, how to you copy files to production? I don't have git installed on the production machine so I can't just set it up as a remote. I know you can do a git hook but I haven't read up too much on that. –  ringerce Sep 3 '12 at 19:05
There are guides around that show you how to set up FTP deployment via a git hook, but I've not used a setup like that to date. –  Jim OHalloran Sep 3 '12 at 23:03
Thanks Jim. You've been a big help. I installed git on the production server. So now I need to ssh into the production server and pull the latest stable trunk (master branch) onto the production server and just repeat the process for future releases? –  ringerce Sep 4 '12 at 0:42
One more question. I found this pretty useful tutorial: sonassi.com/knowledge-base/our-magento-git-guide-and-work-flow/… Do you follow a similar process for staging ? Essentially cloning the live site into a subdomain on the same server and excluding out certain folders? –  ringerce Sep 4 '12 at 1:06
Also, how do you tag your releases using gitflow and magento? Do you just name them accordingly i.e. "template release 1.0" or do you extend magentos versioning i.e., etc ??? –  ringerce Sep 4 '12 at 6:15
show 5 more comments

Your Answer


