Version control, VC, is widely used among larger development companies, but many in our industry assume that it is ubiquitous, and it’s not. Many developers don’t use version control, because there is a perception that VC’s only use is for collaboration among groups. I’d like to layout a case for using VC as a single developer, working alone. It will make you a better coder.
Background
I am a self-trained web developer. As such, I lack any kind of formal training, and like many of my kind, I’ve had to shed bad habits over time. One major bad habit that I’ve had for years is updating code without any sort of modularity or documentation. This has caused me all sorts of pain. My current employer uses Github for version control, and as I’ve settled into this type of workflow, I’ve found many of my typical problems disappearing.
Typical Week, BVC (Before Version Control)
Let me walk you through an example of updating a piece of code using my old method.
I’m working on a new website called FooBar. The project folder is stored on my computer with a local WordPress installation inside WAMP.
On Monday, I start working on a new Contact Us page. I start implementing the page, and as I’m working on it, I see visual bug in the footer. I fix it before I forget about, then return to working on the contact page.
Tuesday, I finish the contact page and then build the homepage, while fixing a few bugs in the header, and another footer bug, along with a bug in a shortcode.
For the rest of the week I continue in the same fashion.
A week later, I am looking at my footer and wondering why it looks the way it does. I think back to the previous week, and remember working on the home page and contact page. I don’t remember anything about the footer though, and I have no record. I can go back and look at the backup copy of the entire folder I made a week ago. I open week-old footer.php, and current footer.php, and scan the files. I see about 16 changes, some of them related to this page, some related to that page. And no idea which change was for what reason. Everything is blurred together.
This is the problem. Changes aren’t modular, and if you look back later, it’s incredibly difficult to understand and remember the reasoning behind code changes. This is a problem that version control can address.
Typical Week, AVC (After Version Control)
Lets go through the same example, with the only change behind that I am using a Github repository with my files.
I’m working on a new website called FooBar. The local copy of the project folder is stored on my computer with a local WordPress installation inside WAMP.
On Monday, I working on a new Contact Us page. I start implementing the page, and as I’m working on it, I see a visual bug in the footer. I commit my current changes to the WIP contact page, describing what has changed and what I have left ToDo. I then fix the visual bug, and commit those changes as well, with a description explaining why I made the change. I then return to working on the contact page.
Tuesday, I finish the contact page, commit changes with description and then build the homepage. As I go, I find and fix a few bugs in the header, and another footer bug, along with a bug in a shortcode. Each time I fix a bug, I commit just that specific change, with a description of the problem and how the code changes fixes it.
For the rest of the week I continue in the same fashion.
A week later, I am looking at my footer and wondering why it looks the way it does. I open up the project on Github, open the footer file, and look through commits related to it. The most recent change tells me exactly what I did and why.
I can look back and see exactly what I did, when I did it, and why. Every commit can and should be modular, and it makes reviewing your own code very easy. More importantly, it helps you start to think in modular terms. Since I started using Git for every project, I’ve started to plan my coding around commits. I work on features as individual pieces that I can describe concisely. This helps with review, and it helps prevent bugs because I don’t touch too much at any given time.
Example of a Modular Github Commit
Here is an example from my Mapstractor project:
The fact that the changes are modular makes it easy to tell, just from looking at the code, what changed. In addition, the description above the changes clarifies even further. Working in this fashion, using modular commits and good descriptions, it becomes easy to set yourself up for success. (a phrase from a coworker of mine that I’m blatantly reusing)
In Summary
Version Control has helped me to change my method of thinking about code. Whereas I used to write code haphazardly and organically, I’m not starting to think about code in modular fashion. Version Control will do the same for you. Even if you don’t work with others, and you don’t collaborate, version control will force you into more modular coding habits. This in turn will improve the quality of your code and make your life easier.
Leave a Reply