Source code management systems have played such a major role in my time as a software developer that I can no longer live without them. Nor would I want to.
Up till now, however, managing source code has always been a source of pain (pun intended). At first it was simply copying entire source directory structures and postfixing them with an arbitrary version number (I was 12, give me a break). The environment was DOS and source control tools were simply non-existent. After a few years I switched to working on unix systems, linux being the only one I could reasonably install, and there I found the tools to do actual version management. . . In the form of RCS and later CVS.
For many years I used CVS and it was a pain. A pox, nay, a plague on CVS. RCS being the progenitor, I curse it too. Times were dark and I wasted many an hour fiddling with the bureaucratic, autocratic and generally odious structures of the time.
I kept at it because the alternatives were worse.
Along came a shiny new system. Its name was Subversion. It rapidly gained momentum, a following and, after a few years, enough mindshare to kick CVS from its throne. That was its stated goal – to be a better CVS. And it did that very well indeed.
But somehow, things still sucked.
The RCS-CVS-SVN chain was predicated on “The Central Repository – All Hail The Single Point Of Control ” approach to engineering. It had many flaws, but the main one was that it did not encourage experimentation. Branching was hard and experiments invariably formed an unerasible part of the source history.
(This is the arrow flashing ‘You Are Here’).
One guy got so fed up with the limitations of existing source control systems that he decided to write his own. Others had tried, but this guy had some weight. Being the designer and arbiter over one of the largest and most complex software systems around his ideas and pieces of code were adapted at a fast rate.
Which brings us to the now.
The new system is Git. Originally developed by Linus Torvalds, it is rapidly becoming *the* version control system for those of us who do not have other systems inflicted from above. If you’re not one of the lucky few, don’t worry – git can bridge to many systems.
So why is git such a big deal? Well, git is de-centralized. Git makes it easy to switch branches, push and pull changes to/from remote repositories. Git can do selective commits on a hunk basis. With git you always work on a local repository, so working off-line is never a problem. The list goes on and on.
Basically, git gets out of your way and lets you work on code instead of bureaucratic procedures.
And with the bridges to other systems, git frees you from the tyranny of the central control point by letting you work on your own experiments and selectively committing them back to “The Central Repository – All Hail The Single Point Of Control (and Access, but sshht, don’t mention that bit)”.
Single control points aren’t bad – in fact they are crucial for doing structured releases. But with many people having identical access to the same point, this system rapidly becomes a nightmare. Git doesn’t require an authority point, so it can be put anywhere, with developers and QA controllers working in a natural tandem.
Git is what comes after sliced bread. Get on it, already.