The way I wish people had taught me Git
The way I was taught and learned git was pretty much learning the sequence of commands to copy the project to my laptop (git clone), to save my changes (git add; git commit), check that was actually save (git log) and push to our server (git push).
So, on this post series, I will show you the way I wish I had learned git. First and foremost, focusing on the Why. Why we need a tool such as Git, why Git in particular and why Git works the way it works. In later posts, focusing on the tool and its commands itself.
There I was, in my early 20s, just got a Job as Jr SysAdmin. The world was changing, “everyone” was shifting their mind to work in a Agile, Devops-oriented, ship-fast-and-often methodologies — at least all the 17 people that I knew.
As most companies in the past few years, we want to ship our infrastructure changes in a fast, reproducible and automated way, to plugin in our code in an automated pipeline. Our “code”, actually; was mostly configuration files and shell scripts for the several open source services we were operating at the time. Services like bind9, apache, ldap, mysql and, eventually; Git and Jenkins server.
On this new amazing world, we want it to have a better control of our configuration: Support easy collaboration between different members, have the history of changes in order to easily revert it, and understand how we got there in the first place. Properly managing the code became a crucial part, as we want to automatically push changes to our servers, we also want to to have the ability to revert and debug it.
That’s where Git came into place. Following a standard git flow, we would copy the code locally, change it, test it, push into the server and merge to where we considered the official version of our code, or, in git terms; the main branch. Once the code was merged, a server, such as Jenkins; will pick the new changes and do what it needs to do to push it over into our servers.
Git, as version control system (VCS) or source code management system (SCM), provides an easy way to propose and accept changes, smartly store the history of changes allowing you to go back and forth, revert changes and so many more features. Just type git help -a or git help -g in your terminal and see for yourself what the version of git that you have installed is capable of.
But, why would you need to keep the history of changes?
Well, the most obvious answer, in my opinion, is to understand what changed in a specific point in time, so you can troubleshoot that nasty, weird, bug that has been impacting your sleep at night. For example, you can ask the user the most frequent question any developer will ask: What version of the software you are running? Based on this information, you check your project history, identify the set of patches (changes) that was merged and hopefully identify what specific change introduced the misbehavior of your software.
Using the example above, you can also chose to revert (using git revert), or rebuild the software from a older version (using git checkout/switch) you can push a new official version to fix the issue, worrying about the buggy-change later. It might sound simple, but this ability to quickly revert a change and worry about the bug later can be crucial for operating your project. Without mentioning keeping you and your collaborators sane.
So, why Git in particular?
Git wasn’t the first and not the last player in the game. In fact, you can achieve the same goal by zipping all your files every time you want to make a release. But, good luck managing that when you need to quickly check the history, study a specific change, switch between versions and finding a smart way to store all that. Git does, at least try; to give you all the tools for that.
Git was created with a very specific, infamous, and huge project at its target — the Linux Kernel — which started to had issues with previously used SCM system named BitKeeper[1]. Linus Torvalds, the creator and maintainer of the Kernel, not happy with the available alternatives at the time; decided to start what is now know as Git. And, obviously, leveraging what Bitkeeper did well for the kernel community.
With this scope in mind, it had to adhere to some requirements, a few of them are: (1) It needs to support the distributed nature of the kernel development, git works by having a full or partial clone of the entire repository locally for you to play with, people can work offline, in different timezone and, as the creator puts its, it creates a distributed backup of your entire project for free; (2) it needs to be efficient in terms of storage and operations, as the kernel code was already big; and (3) support merging sets of patches and even an entire project’s clone, nowadays mostly known as forks, from other kernel’s maintainers. (Check it out the Kernel SCM saga¹ mailing thread to community discussion at the time).
Not only this design benefited the kernel project, git’s efficiency prove to work quite well for smaller projects, with just a few dozens developers or basically every company’s software team, allowing them to easily collaborate, send it over each other’s changes, maintaining an official version of the code and all the history of change for any setback a change might and will cause in the future.
Additionally, git benefited from the experience of the Kernel community, hundreds of developers that was used to work on, as Eric S. Raymond brilliantly defined — the Bazaar model². They could influence, shape and model git to its needs and contribute directly with Git’s code, making it evolve fast after its birth. I bet a lot of companies would like 10% of Kernel developers working for them, while Git inherit that naturally and, eventually; becoming its own thing. Shaping the development world that we are used and take for granted today.
So, next time you do git add && git commit, take a moment to appreciate its history and the easiness it’s to maintain your code and, of course, your sanity.
[1] https://lore.kernel.org/all/Pine.LNX.4.58.0504060800280.2215@ppc970.osdl.org/#t
[2] The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary by Eric S. Raymond.
