I am currently job hunting. Please see my resume and get in touch
This post was originally made when I was a Software Engineering student at Flatiron School
When I first heard of Git, a few years ago, my mind immediately went to oil paint. The popularization of oil as a medium for pigment transformed European painting. Previously the dominant painting medium in Europe was egg yolk tempera, which dried fast and forced the painter to work quickly. Linseed oil’s slow drying gave painters the crucial ability to experiment, which lead to the increased naturalism that was the hallmark of painting of the Renaissance era, as well as the more painterly techniques of the Baroque period.
Of course, now that I have learned more about Git and software development in general, I see the limitations of that metaphor. First of all, while many painters throughout the ages have had apprentices and assistants, this limited amount of collaboration is a drop in the bucket compared to the wide ocean of modern software development, where work is often spread out among multiple teams all over the globe. But it wasn’t always this way. Git is now the standard of version control, but it took a long history to get to the point where we are now.
Version control has its roots in a time before what we think of software even existed. Editions of a book are numbered versions in a way. In mechanical engineering, a component in a larger design would have to adhere to exact dimensions and specifications so that a team of engineers would be able to work on separate aspects of the greater design. As they refined the project, they would be constantly needing to keep track of all the small changes in each part of the design to ensure the all the components continued to be compatible.
In the punch-card era, cards would be tracked in a similar manner, with a person or office in charge of a primary, official version. Even with Bell Labs’ Source Code Control System, created in 1972, only one programmer could work on a file at a time. Systems like RCS and CVS would continue to add more flexibility, but it wasn’t until the launch of BitKeeper in 2000 that fully distributed revision control was realized After years of having no revision control, Linux kernel developers were increasingly frustrated. Finally, in 2002, Linus Torvalds chose to use Larry McAvoy’s BitKeeper, a closed-source system, which led to immediate controversy in the open-source world. But to Linus, the distributed system simply had too many benefits to choose any of the existing open-source solutions.
The open source community continued to try to develop their own alternatives to no avail, until 2005 when Andrew Tridgell attempted to reverse engineer BitKeeper, in direct opposition to McAvoy’s warnings. Suddenly the entire Linux kernel development was without a revision control system. Torvalds, for the first time since 1991, stopped work on Linux and after a brief time emerged to show the beginnings of Git, which would continue to be developed by the open-source community.
Fifteen years later, Git is by far the most popular version control system in the world. Git continued the idea of a distributed system from BitKeeper. No central server means everyone can commit and branch locally and work together anywhere in the world. These features, initially especially attractive to the open-source community, have also been a large part of its success in all sectors of our increasingly connected world.
For good measure, I’ve decided to include some information on some Git commands that I hadn’t come across before doing research for this blog.
git cherry-pick
https://git-scm.com/docs/git-cherry-pick
git cherry-pick is a powerful command that allows you to take a commit from one branch and apply it to another. First you find the commit reference for the commit you are looking for by running git log then git cherry-pick commitSha where “commitSha” is the Sha for that commit.
Although not always best practice, this can be useful in certain scenarios, like when you are working collaboratively and there is a bug you need hotfix.
git blame
https://git-scm.com/docs/git-blame
This humorously named command can let you see line by line, who changed what is a specific file. You can run it with git blame filename
If you object to the name, you can add an alias to something more positive like git config — global alias.praise blame
git stash
https://git-scm.com/docs/git-stash
Git’s stash feature allows you to temporarily “stash” your changes, separate from your repo, staging area, or working directory. That way, you can save changes that are not ready to commit when you need to switch over to another branch. To stash, just run
git stash save “put whatever message you want here”
To see what is in your stash, use git stash list
git stash apply stashName applies a change but keeps it in the stash, whereas git stash pop stashName applies it and removes it from the stash.
So, just to conclude, while my analogy to oil paint wasn’t a perfect comparison, I feel I got the spirit right, in that while oil painting encouraged experimentation, Git has allowed experimentation and worldwide collaboration, a sort of multidimensional, hypertextual version of what happened in the painting world of the 1500s.