Boss your VCS

If you haven't worked it out by now, you should be using version control. I'm not going to tackle that topic today, there are plenty of good reads explaining the reasoning behind that statement.

What I want to talk about today, is what I mean by bossing your VCS, and why it is important for you to do so.

If you are completely avoiding giving yourself even a rough understanding of the underlying architecture of your VCS, you're probably not bossing it.

This isn't a "you're doing it wrong if you're not using the CLI" rant, or at least I hope it doesn't come across as such, so I'll start with this, by all means, feel free to use a GUI. I used one for my first couple of years of using VCS (Tortoise SVN to be specific), and now that I use Git, I still use gitweb on occasion when I need to widen my perspective of what's going on, its beauty may not make me weep with joy like the GitHub app or Tower, but it can help when assessing complicated setups.

This is a discussion on why you should work out what is happening when you press your shiny 'sync' button, so that when it inevitably does something unexpected, you can theorise as to the cause and possible solution to the problem(s), or at the very least ask someone who can.

A good portion of VCS users are frontend devs or designers, and I totally get that these are typically very 'visual' people, and that is by no means a criticism or a fault, it's great, but I don't see it as an excuse to avoid learning about your VCS, you don't need to know everything about it, but a basic understanding of what's going on when you execute commands is key to leveraging the power of the tool you're using.

In most VCS GUI's, the basic functionality such as; committing, browsing logs and performing differentials tend to work pretty well. The main problems hit home when one of the following happens:

  1. You need to work with lots of branches, tags or remotes.
  2. You need to work with a team doing more complicated stuff than your GUI was designed to handle.
  3. You (or someone else) makes a mistake.

Disaster recovery in VCS GUI in my experience is particularly poor. To the untrained eye, your work is gone and the walls are crumbling around you. Which is a shame, because in actuality, particularly if you're using Git or a comparable modern VCS, it's pretty damn hard to lose your work; if you committed it at some point, and you haven't been messing around with index files, it is almost always recoverable- you have to go to considerable effort to rip commits out of a repo, so trust me when I say, you probably don't know the commands to do it, I don't, and I doubt any GUI's use them haphazardly.

I'm not going to lie, CLI is probably the easiest way to get to grips with this stuff, and if you haven't quite got the hang of basic directory traversal yet, you're probably going to need to get a handle on that first. My main thinking behind this is that the CLI tools don't sugar coat their interactions or cut out steps. In my opinion, the GUI's that wrap several processes into a single button do a lot of harm by encouraging common misinterpretations of how these systems work, and when any of the steps break down, recovery can be difficult for the novice user, ruining the enhanced experience they were looking for from their GUI in the first place.

In almost all VCS, CLI and GUI aren't mutually exclusive tools. Your VCS' CLI is just another client much like your chosen GUI, they both process the same index files, and can perform the same basic tasks, the key difference is that the CLI client will be far more feature rich, but at the end of the day they should be able to operate in perfect harmony.

In fairness, it's not at all surprising that so many choose to avoid CLI tools like the plague. At the time of writing, git-cli tells me that there are 127 commands. Wow. Understand however, that whilst I'm no Torvalds, I consider myself relatively proficient with Git, and I know and make use of approximately 10 of those commands from memory, and an additional 5 or so I can Google for as and when I need them. The key is the fundamentals, such as in Git's case, what it means to be using a distributed VCS, how staging, committing, pushing, pulling, merging and rebasing works, and what their relative significance is, understand those and the rest is pretty easy.

Further reading: