The Most Useful Tool Writers Don’t Know About
Wouldn’t it be good if a system existed that recorded what you were writing, and allowed you to look back at past changes — to find out how the text evolved? It already exists.
First the backstory
In the daytime I work as a software and web developer. It’s the kind of job where you need to wear many hats, because projects tend to start out as conversations, then become documents, then prototypes, and finally installed solutions. Along the way, project documentation and source code will change endlessly.
When you’re working alone on a project, looking after your files isn’t a problem — but when working as part of a team on a bigger project making changes and distributing those changes to the rest of the team can become a nightmare — unless of course you have a magical piece of software that can do it for you.
Back in the early 1990s, a software developer in Finland started working on a new operating system which caught the imagination of his peers, and rapidly spread throughout the world. The developer was of course Linus Torvalds, and the operating system was “Linux”. Over time, integrating the combined efforts of thousands of developers became a nightmare — so much so that Linus stopped working on the operating system for some time — in order to find a better way of working together.
Within months, Git was born.
What is Git?
Technically speaking, Git is a federated and decentralised version control system. You can submit files to it, and request files from it. In return it keeps a secret database of exactly what has happened to each file in-between those submissions. It can also keep track of multiple copies of the same files, and even merge the copies back together for you.
Imagine you’re writing a novel, and you’re not quite sure where the story should go next — so you write several potential outcomes. These alternative outcomes are “branches” as far as Git is concerned, and it has no problem at all keeping track of them for you.
What does federated and decentralised mean?
Git doesn’t “live” anywhere in particular. There is no special “origin”, that all roads lead back to. When you take a copy of work done so far on a project ( called “cloning”), you’re taking a copy of the entire history of the project — everything that has happened to the files within since they were first added.
Given that everybody working on a project has a copy of everybody else’s work, you need a way to communicate changes to each other — that’s called “pushing” and “pulling”. Essentially, two disparate systems can be instructed through a “pull request” for one to ask the other “how are you different than me?”, and to work out what needs to be changed.
It’s all very clever, but much of the cleverness is hidden from the user, which is wonderful.
How can I try it out?
Head over to GitHub and sign up for a free account. Download and install the client software for your computer, and start exploring. Github can be thought of as a robot user in the cloud — somebody you can push your work to, that will keep it safe for you.
You don’t have to use the GitHub software — most software developers use Git directly from the command line — but the learning curve is much steeper than using the client software. You don’t actually need GitHub either — you can just install Git itself, and start using it — that’s another subject for another day though.
One more thing…
Git was originally designed to deal with programming source code. That means it’s fantastic at dealing with text files. While it can also manage binary files perfectly, it won’t even attempt to figure out what has changed within a binary file. Therefore, if you write in markdown, you’re going to be Git’s best friend. If you don’t… well… you might as well just save your work to OneDrive.
Originally published at https://jonbeckett.com on December 12, 2020.