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