Version control is a system that records changes to source code over time. Giving you a log of who changed what, when, and the ability to go back to any defined point in time. You can make massive changes to your source code and then, when you’re done experimenting, just throw them away, or commit them. Version control is essential for working in teams on software projects, it allows for control over who is editing what, produces a log of who made which changes and why, and deals with merging files when two or more people have made changes. It allows you to have different versions of the same project (master in production, development on staging and feature branches)
Humm, this looks complicated, why bother with version control?
Collaboration
Before version control, you probably had a single set of files on a shared server everyone could access, and you would have to manually coordinate who was working on which file at any given time. If two people were working on the same file at the same time, changes would quickly be lost and time wasted. Version control allows everyone to their own local copy of all your source code, which they can edit at will. Changes are then merged back into the main repo.
Who did what
Code must be committed to the repository. This means that it has to be explicitly added to the system as something that its author has vouched for. The commit contains the code that was added or changed, the date it happened on, a message explaining the change and the authors name. Now we have a record of who did what during the development of an application.
Disaster recovery
Version control is best set up to be distributed. This means at minimum, your work exists in at least two places; your local development copy and the version on your version control server.
Change Control
Version control allows you to have, and swap between, multiple versions of your project easily. As you develop and release different versions of your project you may need to keep different versions around, for bug fixing and patching security holes. You can also allow or disallow people for making changes to the code by enforcing pull requests and code review before new code gets added to a working project.
WordPress and version control
Version control is awesome when you’re building a WordPress project in teams, it lets multiple people contribute code to your project all at the same time without having to worry about overwriting anyone else work. Even if you’re working on your own, version control is useful for creating separate branches of your code. Master, development and feature are common branches in WordPress client work where master is in production on a live server, development is on a staging or testing server and topic is being worked on by a developer on their personal computer.
Say you have a master branch of your site that is deployed to production, it is live and people are using it. You set about making improvements to your site or app and all of a sudden, someone finds a bug, a bad one, something terrible like your login form is insecure. You set about fixing the issue immediately, but you can’t deploy your fix because your working version is filled with half done features and even more bugs! If you had made a development branch from master and worked in there, you could just have switched branches, fixed the bug in master, deployed that and then merged the fix back into development. This is the real beauty of version control, it allows you to maintain an application in various states and versions with multiple people working on the project.
Okay, I’m sold – How do I set up WordPress with version control?
We will use Git for this tutorial, it’s a very popular, flexible version control system. We will assume you have some knowledge of the command line, but follow along with the commands and get started, this won’t damage your computer at all.
Concepts in Version Control/Git
Git can seem a little complicated at first but when you get your head around it, it really makes sense. All code exists within a repository and a repository is a complete copy of a project including all of its branches. A branch is a convenient way of splitting your code into different versions so you might have a v1 branch and a v2 branch. v2 inherits all of v1 as it was when the branch was made. Changes made in branch v1 can be merged into branch v2 and vice versa. Code is added to a branch via a commit. A commit happens when you make a change to a file and add that to the repository. Commits belong to a particular branch. Repositories are distributed and linked, you will likely have a remote origin server that acts as the source for everyone acting on it. Changes you have made to a repository can be sent to the remote server via pushing, and changes made by other people can get retrieved by pulling.
Getting Started With version Control
We will look at a very simple example of getting started with version control in the context of WordPress. This example is overly simplified to help get the idea across and I wouldn’t recommend using this for a real project.
First off – Install Git if you haven’t
Open up your terminal and find somewhere to work that can be accessed by localhost (or 127.0.0.1) Make a new directory and change into it. This will give us somewhere to work.
mkdir git-wp
cd git-wp
Now we want to tell git that we want to start using this directory as a repo, run this command in your terminal.
git init
Git will now create a .git folder and start to track changes made to files in this directory.
Next we need to add some files for git to track. Download a copy of WordPress and paste it into your git-wp directory.
Now run git add . this will add all the files we just added to Git’s index. Now run git commit -m “initial commit” this will commit the files to to the repo, assign it a commit id, and the message you included will be added to the commit logs. Your code is now officially a part of the repo!
Finally, let’s push the repo to a remote location that will become the origin source of all truth. Go to BitBucket and sign up from a free account. Create a new repository and select “I have an existing project to upload”. Follow the instructions BitBucket provides for pushing your repo up to them. (You could also use GitHub, if you don’t mind your project being public).
Now when you work on your project, follow these steps. You make some changes, add them to the index, commit them to the repo and push them up. Now you have a remote copy of your work, just incase something goes wrong.
git add .
git commit -m "descriptive message about the change"
git push
Going Further with Git
What about if we want to work on an experiment, something where we will need to change loads of files, something that would be a pain to undo. Run git checkout -b test-branch. This will create a new branch at the same point your master branch master was at. You can do anything to want in this branch. Do something stupid, link delete index.php and break the project. Now, you have two options, git reset head will return the branch to the last commit made. Or you could swap back to master by running git checkout master. On the other hand, say you created an awesome new feature, works great, in your new branch – you can merge the branch into master, making it part of your project. Branches are a great place to work on new code, it means you can check out your master branch anytime to fix a bug there, just imagine how much time and effort that could save you over the course of a long project.
Better Version Control for WordPress
Components & Modules
It is important when working on software projects that you think in terms of modules and components. WordPress is not your project, WordPress is just a part of your project. To enable this we need to remove everything in WordPress that we might need to edit. WordPress can take care of this for us. Go into your project folder, create a new folder /wordpress and copy all of your files into it except index.php, .htaccess and wp-config.php.
Edit index.php and change the path for wp-blog-header.php to wordpress/wp-blog-header.php. This will tell WordPress to load itself from a different directory, WordPress will also look for wp-config.php one directory higher. We have now removed all the things we need to for a basic Git setup in WordPress.
There may not seem to be a lot of point to that just now but when you start using Dependency Management with your projects, this will help a lot.
Keeping Secrets out of the repo and having different environments using .gitignore
Its a bad idea to include anything confidential in a Git repo, once its in there it’s hard to remove. lets create a new file local-config.php. Copy your database credentials from wp-config.php into local-config.php and delete them from wp-config. In wp-config, include local-config.php. Now create a new file .gitignore. Gitignore is a special file, it tells Git to not index and watch particular files. In this case it is ignoring our database configuration options for our local setup but it could also be setup to ignore files that are preprocessed or caches from operations.
Git and version control is just the start of what we can do when we start to add advanced techniques to our WordPress development workflow. Have we missed anything or do you have questions? Reply in the comments below and we’ll be glad to help.
