A quick review of previous entries in the Library section of this magazine shows that it does not feature any book from The Pragmatic Programmers, for no other reason than gross oversight. We have discussed books from MIT Press, Addison-Wesley, O’Reilly, and many other publishing houses, and now it is time to solve this issue. This month we will elaborate on “Pragmatic Version Control Using Git”, a 2008 book by Travis Swicegood.
In other circles than software, such as physics or literature, the year 2008 would undoubtedly be called an annus mirabilis. While the “real world” was grappling with one of the most severe financial crisis in history, the software industry saw a miraculous conjunction of factors, seemingly happening within months of one another. Let us enumerate a few: in March, the availability of the iPhone SDK. In April, the launch of GitHub. And in September, three major events: the announcement of the Google Chrome web browser on the 2nd, the launch of Stack Overflow on the 15th, and the release of Android 1.0 on the 23rd.
Couple all this with the meteoric rise in popularity of AWS and cloud computing in general, the phenomenon of social media, and the explosion of Web 2.0 and “Ajax”, with the ubiquitous presence of libraries such as jQuery and Prototype.js. You could feel that software engineering was never going to be the same from that point onwards. It was undergoing a profound transformation, live, in front of our eyes.
It was both a terrific and terrible time to be a software developer, and Git appeared as one of the hottest new tools to check out. But Git was also substantially different from anything many of us had used up to that point. At least for me, the whole idea of a distributed source code management system was completely alien.
Up to that moment I had been a happy Subversion user, hosting some of my code on Google Code and even running Subversion repository servers on my own machine–I admit, a rather clumsy setup for a single developer. Before Subversion, I had used various source code management tools: Rational ClearCase from 2002 to 2003, Visual SourceSafe from 2004 to 2005, and CVS from 2006 to 2007. (Yes, the list shows a clear regression; it seemed that the further I advanced in my career, the dumber and more unstable the SCM of my employer would be. Anyway.)
All the systems enumerated above are client-server, and thus, centralized; there is a server, somewhere, and a small client on my laptop allows me to check code out, commit changes, and voilà. Need to blame a file? Talk to the server. Want to see the full history log? Talk to the server. Want to create a branch? You get the gist.
I remember attending a talk about Git during a community meetup in March 2008, and rushing back home to order a book about it on Amazon (Kids: e-books were just starting to appear on our radar, as the original Kindle was launched in November 2007. So, physical book it was.) There were not many books published about Git (yet) and I had always enjoyed reading books from The Pragmatic Programmers, so choosing this month’s Library book was a no-brainer for me.
Needless to say, this was the perfect book to open my mind to the possibilities of Git. Just like in many other Pragmatic Bookshelf titles, the introduction to the subjects is gentle, complete, yet entertaining. The first chapter was particularly helpful, with its explanation of the differences between distributed and centralized version control, and the resulting workflows that were possible in each case.
The conceptual part was the most challenging one for me, but the author made it abundantly clear that it was not that hard. And the highly practical nature of the book, filled with examples, made understanding Git fast, straightforward, and simple. The detachable “Git Command Quick Reference” sat on my desk for months, providing a much-needed reference until most commands were engraved in my mind.
The rest is history. When I started my own business in 2008, I got a paying GitHub account and used it to host the private Git repositories of all of my customers. But some of those customers were not entirely used to Git or distributed source code management for that matter, and asked me to push code into their Subversion repositories; no problem at all, git svn to the rescue.
Git was a godsend during those years of independent consulting. I was very frequently on the go, either on a plane or on a train, without any network connectivity, and Git allowed me to work perfectly well, committing, diff’ing, blaming (mostly me) and branching as much as I needed, at any time, in any place. As soon as a network connection became available, a simple git push would share those changes with my customers, and even better, trigger some automated task in a CI/CD system somewhere.
Beyond my own developer experience, one thing that changed in the software industry from 2008 onwards was that Git became the all-encompassing source code management tool, while others slowly disappeared into oblivion. New developers joining the workforce learned Git exclusively. New businesses started adopting Git and collaborating on GitHub or GitLab repositories. Popular software projects started opening up shop on GitHub. Text editors started providing built-in Git support. Everyone started assuming that Git was the big default SCM of the world of software. Well-known SCM packages slowly faded away. Companies providing commercial SCMs went bankrupt or pivoted to other markets.
During the past 16 years, I almost exclusively used Git for my code and my projects, both personal and professional. I did use Mercurial too, for a while at least, but for no other reason that my employer at the time was a heavy Python user. They ended up migrating to Git at some point, the power of networking effects being too difficult to counter. Those forces even bent BitBucket, originally a Django web application hosting only Mercurial repositories, to drop Mercurial support in 2020. Sign o’ the times.
The writing was on the wall. Git is the de facto standard, and it has become as ubiquitous as the English language, or water. Travis Swicegood’s book still sits on my bookshelf; admittedly, I do not consult it so often as I did in those early days, but it represents a pivotal moment for my career–and truly, for the whole industry.
Cover photo by the author.
