This article is part of a series created in partnership with SiteGround. Thank you for supporting the partners who make SitePoint possible.
Many developers may wish to use version control with their Magento site as they develop it, and perhaps continue doing so as they maintain and add to the live website. Here, we’ll focus on Git as the version control system of choice. This article is meant not as a step by step instruction, but rather a set of tips and things to consider when you’re working with Magento and Git.
Why use Magento and Git at All?
Magento is one of the world’s most popular and innovative ecommerce platforms. With a huge customer base and countless developers building applications in it, extending and theming it, Magento is an excellent choice for ecommerce websites.
Git is similarly the leading version control system of the day. There are many places to go for Git hosting, such as GitHub or BitBucket, (What are the Differences Between Git and BitBucket?) and Git is the easiest VCS to use if you want the most developers to be familiar with it, as it’s used everywhere, and for all manner of projects, ranging from single page private sites to massive production applications.
Why would you want to version control your Magento site with Git? That’s an easy question to answer as well. When creating or altering things like themes or other custom coding, you’ll want to make sure those changes are not only saved, but also that your retain the ability to easily roll back changes. You’ll want the ability, perhaps, for other developers to clone your working setup and add features or fixes as well, or to easily deploy your site code to another testing or staging server. Git can help with all of that.
Deciding What to Include in the Repository
One of the first decisions is what exactly to include in the repository. This is going to depend heavily on your use case.
First, Decide on Your Approach
First, you’re going to have to decide on your approach. What is Git repository for? Do you wish to store your entire site? If so, you’re going to have to make note of items that you do not want to store in the repository. This might be useful if you have a small team and find it easier to just pull down a large Git repository containing your (almost) entire site, rather than setting up Magento in a new environment, and then pulling in only a few assets from a Git repository.
On the other hand, perhaps your team is already set up with substantial build tooling, and able to deploy the same version of Magento and other software to any environment without trouble, and you really only want to version control the specific files that are under development.
Knowing your approach will dictate the rest of your Git decisions with Magento.
Consider Databases and Configuration Files
Some Git teams do database dumps to files that are inside the Git repository, so that when creating a new environment, as soon as the repository is pulled down, you have a relatively recent copy of the production database for use in setting up the new dev or test environment.
Other teams might balk at this. It may depend on your situation, and perhaps more importantly, on your team and project’s security. If the project is open source, or is open to a large section of your own company, even, you may not want to be including copies of your database files, as this would be grossly insecure. Shared amongst three developers on a private repository, for a startup app that is still under development and not in production, it might be exactly what you want. However, if you don’t put database dumps in your repository, you will need to create a process for sharing database files in order to create cloned environments as needed for development and testing.
Configuration files are treated much the same way. Typically, you are going to want to keep
magento/app/etc/local.xml out of your repository if you have any security concerns at all, because of the credentials stored within it.
How to Handle Images
/media folder can become quite massive for large Magento installations. When it’s below a certain amount of content, perhaps during development or early stages, it may make sense to include it to have image content for testing in other environments. When it starts getting too large though, it may just make more sense to ignore the entire thing, and then perhaps use a fake image set for test environments.
Setting up Your .gitignore
Once you’ve made your decisions about what you want in your Git repository, the next step before beginning to use Git is going to be to come up with your
.gitignore file contents (the items that will be ignored by Git when pushing to or pulling from your project repository). This
.gitignore file goes at the root of your repository, and instructs Git on files to ignore. It may be a relativelty small list, like the below, or it might cover the majority of your application – that’s up to your strategy for version control.
magento/app/etc/local.xml magento/cron.php magento/cron.sh magento/errors/ magento/install.php magento/LICENSE* magento/media magento/RELEASE_NOTES.txt magento/robots.txt
Note that this isn’t a complete .gitignore to copy and paste, but just a set of ideas – you’ll want to decide on additonal items to remove or add to this list, depending on your own project’s needs.
You also might want to take a look at the contents of your
.htaccess – if they are specific to your environment, that may need ignored. You may also want to ignore some or all of
var – caching, errors, etc. may be unnecessary to commit to source control.
You’ll want to make sure and consider your Git repository’s security. Who has access to the repository, and do they have read or write access? Do you alter or revoke permissions when a user changes roles or leaves your project? Is the project open source or private? Could it ever become open source? These are all considerations when you first set up your repository.
Branching Structure and Environments
Another thing to consider right at the beginning is your branching structure. Many projects have something similar to the following:
- Development - Staging - Production
But of course you can tailor the branches to your needs. You could have temporary branches, for say theme development or custom features, then merge them into the development pipeline when complete. The strategy is up to you, but the important part is to plan it out and execute it, and not fall into the trap of commiting everything to the
master branch in your repository. Branching is part of the reason you use Git!
Learn PHP for free!
Make the leap into server-side programming with a comprehensive cover of PHP & MySQL.
RRP $11.95 Yours absolutely free
Finally, you may want to consider your deployment strategy as well. Are you going to deploy using Git on the production server? Will you use an outside service, such as DeployHQ to deploy via FTP when your Git repository is updated? Or will you do deployments manually?
SiteGround offers a Git integration that is quite handy for developers who are using their hosting.
With careful planning and setup, Magento and Git can work hand in hand to provide you with a better, more secure site and a much more efficient development strategy. Get out there and build awesome ecommerce platforms with Magento and Git, and keep them safe and productive!
Jeff works for a startup as a technical writer, does contract writing and web development, and loves tinkering with new projects and ideas. In addition to being glued to a computer for a good part of his day, Jeff is also a husband, father, tech nerd, book nerd, and gamer.
Jump Start Git, 2nd Edition
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers