This article is a response to “Version Control: Important for Individual Projects?”
The aforementioned post suggests that using VCS is imperative when working in a team but optional, albeit helpful, when working alone.
Upon reading the original article, I found myself agreeing with the majority of points. Yet, I felt that the author did not quite do the positive case justice.
It is for that reason that I have written this response to expand on some overlooked points and offer my own insight.
The summary of the linked article starts by suggesting:
“[Version Control] is used to track and record every aspect of the development of software including who has made changes, why they have done so and to what the changes and additions refer to.”
I feel that this statement is misleading as it seems to conflate the role of raw VCS and providers, such as GitHub, that offer extra services.
Tracking the ‘why’ behind software development is often better suited to a project management tool such as Basecamp  or Trello . Git simply stores a series of file updates (nodes) and an ordering (edges) in a graph. The stages of development when producing a conceptual solution do not necessarily map to a linear progression, so VCS alone may not provide an adequate record.
In contrast, GitHub  provides excellent Issue-Tracking and Pull-Request features that aid in software development.
The summary continues to offer:
“[a VCS’] working copy is the most up-to date version of the software or the ‘head’ but previous history and iterations are saved and can be viewed as needed.”
This describes only a limited usage of a VCS, like Git,’s full potential. When using an approach such as the Feature Branch Workflow, there is rarely a most-up-to-date branch. Instead, many development branches provide a partial ordering of changes. Disjoint features are advanced concurrently. There may be a release branch that is most-up-to-date of all integrations, but this would not include changes present in un-merged feature branches.
Later, in the discussion, the author mentions:
“Merging your edits with someone else’s can be very difficult or they can break the code completely, unfortunately there is no way around this.”
This suggests a scenario where the Feature Branch Workflow may come in handy.
Git’s merge features can usually handle changes within the same file admirably. This is especially true when options such as “patience merging” are enabled.
Any remaining merge conflicts may stem from too many people changing the same function or submodule within a file. This is often a bad sign as it is unlikely that a single component is critical enough to need many programmers constructing it in isolation. It is far more likely that it is a case of “too many cooks” combined with a poor separation of concerns.
Instead, the module that is requiring continual adjustment by many can be split into separate components.
Components can be developed on disjoint Feature Branches and merged into an integration branch when completed. By fixing the interfaces of each component, a single component can interact with one from another branch. This lessens the need for continuous merging of partially-completed implementations.
The original article claims:
“[Using VCS] ensures that everyone is consistently up to date with the latest version of the software. These advantages do not apply for an individual developer.”
I disagree with the suggestion that a sole developer cannot benefit from distributed versioning.
During the course of my Master’s project I developed low-level software concurrently on a laptop and PC. The majority of system code was shared, but features and optimisations were developed independently for a particular device.
Using VCS, shared code was pushed into the release branch and merged into both feature branches. This task would have been much more challenging without the ability to juggle dependencies via branching.
Another quote from the original article that I would like to draw attention to is as follows:
“breaking the code [is] no longer such a hassle since you can always revert back to older versions where all the information is present and works.”
I agree that a major benefit of VCS is the ability to rewind in worst-case scenarios. However, I feel uneasy at the idea of ‘rewinding’ being advertised as a killer feature, as opposed to the safety net it provides.
Prior to development branches being merged in, integration tests should be run to ensure that the existing system will not be broken by code addition.
In my opinion, using the ‘rollback’ feature of version control should be avoided in favour of eradicating sloppy development practices.
The author sensibly states:
“Keeping track of who did what can also be quite important when debugging/trying understand what is going on or when creating documentation”
…but then argues that this is not significant when working alone.
I have anecdotal findings to the contrary. I have found the ability to “review history” incredibly useful, both when working in teams and alone. The ability to view a diff over a custom period and see the previous direction of progression has proven invaluable after taking some time away from development. The information it provides eases the act of “getting back into the swing of things”.
“If a third party controls your repository, this can also double up as a back up of your project”
This statement is entirely true. However, having your development repository solely in the command of a centralised third-party is generally a Bad Idea™.
There have been many cases of service provides, such as GitHub, suffering from DDoS attacks and technical failures.  When this happens, you could be left unable to commit work and progress can grind to a halt.
Instead, work can be pushed to personal, distributed repositories in addition to a single service provider.
In the article’s conclusion, the author stated:
“Version control is not completely necessary for the individual programmer since a lot of the reasons why this tool is so useful do not apply in this circumstance, and those that do are not essential”
I disagree that individual programmers should go it alone without Git as a sidekick.
Yes, Git is definitely poorly designed for beginner usage. For example, you may wrongly expect “$ git branch” to allow you to change between branches instead of the “checkout” command. This contributes to the unwillingness that many new users have towards learning Git.
Yet, the fact that it is so critical for large teams means that it is far more useful to use it in your own time so that you can become accustomed to it. There are plenty of guides available and even some great in-depth learning resources about how Git works .
(PS: I’d really recommend reading that last link if you are interested in painlessly discovering how Git really works)
Using Git for personal files in general allows you to have an audit trail, something that you rarely appreciate fully until you need it.
The author stated that they have not yet been saved by VCS on a personal project. I believe that this is akin to stating “Seat-belts aren’t essential as I have never crashed!”
For example, by putting all of my configuration (dot)files into a Git repository, I can easily check which esoteric hack fixed a particular obscure bug.
In addition, you can leverage the power of automation to pinpoint the exact moment that you introduced a flaw into any system — often saving lots of time. 
In conclusion, I believe that Git is a valuable tool that is well worth the time investment to become familiar with. I think that although it is technically non-essential, it is a false-economy to not use Git whenever possible. It takes so little time to set up that the benefits largely outweigh the costs.