Some of you may know I’ve started a new job recently, as a Senior Infrastructure Developer. The word developer there means I have to come to grips with source control in general and git in particular. I wanted to make a few notes on this here.
What is git?
Git is a distributed code management system, at times you “commit” your files into the repository where it is forever remembered. It stores a sequence of remembered snapshots, and you can even “branch” the sequence to work on different features before bringing them together. It differs from older source control systems like cvs and svn you may have seen in the past with one key fact. There is no master node. Every node has not just the copy of the files in the current branch, but all the files in every branch, and all the history too. “Checkout” is no longer a remote operation, it’s a local one, placing the files for the requested branch into the local filesystem, from the local store. To copy files from a remote or shared repo use “clone” the first time and “fetch” afterwards. With git, developers can work offline with full power and history.
But you said local?
All this means that git is also useful for local only projects. No master repository necessary, no-one to sync with, and still there is a lot of value.
Backups, are more important than most people realise. Of course a local git repo won’t protect you against catastrophic disk failure, but it will protect you against the much more common accidentally deleted files. Also common is the “I played with my program too much and now I don’t know why it doesn’t work”. Which brings me to…
History, logging what you’ve done and saving precious states is incredibly useful. Git allows you to save state at any point, and switch between them at will. It tracks changes on a line by line basis inside the files and can tell which parts of the file have not changed, perfect for code. You can switch to a previous state, test or look, and then switch back to your current state. Without risk of losing anything, and without copies of your code everywhere.
Branching and merging sound like something that only serious programming teams need to do, but the concept can be very useful for solo or at-home programmers too. In short, this allows you to work on different things at once. Say you wanted to stop writing this blog post for a while, and work on the theme for your site. You could make the theme updates in a branch, so that half finished and broken themes don’t stop you releasing the post. Just checkout the main branch and run your post update from there.
Checkpoints, are I guess a subset of history. It’s easy to tag your code before you start a big job with “working”, or after with “includes feature”. You can then easily come back to this at any stage.
Sharing and accepting, is easy with “pull requests”. I can clone a copy of someone’s project, add my changes and submit a pull request to the original project. The manager of that project can easily see the differences included in the request, and accept them into his version. I can fork their project and continue to work on it myself. Git is at heart a tool to work with other programmers, so this functionality permeates everything it does.
Is this for me?
Well, it’s not for everyone. If you’re still unsure, the question becomes “do you have multiple copies of your project directory?” Perhaps to save state between features, backup up a working copy, or test new ideas. If the answer is yes, I suggest giving git a try.