The world of software development turns on the axis of Git and GitHub
This feature first appeared in the Summer 2019 issue of Certification Magazine. Click here to get your own print or digital copy.
Looking back isn’t always a great thing to do, but you are almost certain to encounter positives when you keep context in mind as you make your way down Memory Lane. My purpose in this article is to explore the past, present, and future of Git, a subject that’s near to my heart. Why is Git near to my heart?
I have long been a believer in being able to look back over the course of time and trace the positive impact of change. Change always comes, sometimes too slowly to see if you aren’t watching for it. Git is a distributed version-control system for tracking changes in source code during software development.
Git is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows. That, at least, is how all of the internet articles typically define Git — I have a different viewpoint.
I think Git allows you to be part of a community of positive change that pushes whatever you are doing to another level. It allows what you’ve created to flourish and allows others to nurture it beyond even what you, the expert, may have envisioned.
“Programming” has become a catch-all phrase to describe a realm where handy buttons and phone apps can make anyone a participant. For programmers of the sort who use Git, a new term is catching on: collaborator, or even expert. You can’t get by on that playing field with smoke-and-mirrors gimcrackery.
That being the case, when potential employers ask for Git-related skills, what are they asking for, really? How do you immerse yourself in Git and learn what it takes to thrive there? And finally, what does Microsoft’s acquisition of GitHub mean for the future of Git-driven development? I recall my early days in technology where we used TFS (Team Foundation Server), an early Git-like Microsoft product. We have thus come full circle.
What is Git?
At a nuts-and-bolts level, Git is simply a version control software. It lets users distribute their development project to the masses for review and discussion. Formal and informal partners create and build on top of whatever it is you’ve released.
In physical terms, suppose that you want to build a pyramid, so you lay a brick down. Someone lays a second brick, and someone else lays a third. Someone notices that your original brick is crooked, so they adjust it. At its core, Git provides distributed access to a range of collaborators. No one really owns the pyramid — after every brick is laid, it belongs to everyone.
Git development goes back to April 2005, when a number of developers of the Linux kernel walked away from BitKeeper, a proprietary source-control management (SCM) system that they had formerly used to maintain the project. The copyright holder of BitKeeper, Larry McVoy, had withdrawn free use of the product after claiming that Andrew Tridgell had reverse-engineered the BitKeeper protocols.
You can look up the details of how these early software engineers fought back and forth, and what came out of all their dealings with each other. It’s good, quality reading enjoyment, albeit in retrospect, though these conflicts shaped the current development landscape, many of them now seem more like quibbles than battles — petty and small.
Linux godfather Linus Torvalds wanted a distributed system that he could use like BitKeeper, but none of the available free systems met his needs. He wanted a way he could get others to help and collaborate. Torvalds cited an example of a source-control management system needing 30 seconds to apply a patch and update all associated metadata and noted that this would not scale to the needs of Linux kernel development, where synchronizing with fellow maintainers could require 250 such actions at once.
The development of Git thus began on April 3, 2005. The first merge of multiple branches took place on April 18, 2005, marking the first time that multiple code bases and collaboration took place — a historic first that probably seemed like just another April day. Torvalds turned over maintenance on July 26, 2015 to Junio Hamano, a major contributor to the project. Hamano was responsible for the 1.0 release on Dec. 21 of the same year and remains the project’s maintainer.
Torvalds quipped about the name “Git” — a British slang word with the same essential meaning as “idiot” — “I’m an egotistical bastard, and I name all my projects after myself. First Linux, now Git.” Its man page describes Git as “the stupid content tracker.” The readme file of the source code elaborates further:
The name “git” was given by Linus Torvalds when he wrote the very first version. He described the tool as “the stupid content tracker” and the name as (depending on your way):
● stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
● “global information tracker”: you’re in a good mood, and it works for you. Angels sing, and a light suddenly fills the room.
From Git to GitHub
In 2019 we have GitHub, which actually originated not all that long after Git. First launched in 2008, GitHub came into existence as a web portal of sorts for teams or individuals to set up and carry out development projects using Git. By late 2013, not quite six years after its creation, GitHub was hosting more than 10 million projects on behalf of more than 3 million users.
Today, GitHub brings together the world’s largest community of developers to discover, share, and build better software. You can collaborate with people from all over the world, or with your own private teams. It’s a central object and code repository accessible on the internet, anytime you need it or care to use it.
You simply create an account and start interacting. Git enjoys great community support and a vast user base. Documentation is excellent and plentiful, including books, tutorials, and dedicated web sites. There are also podcasts and video tutorials. Storing your work in Git is more or less standard practice for many programming teams.
Git ‘skills’ are hot
With tech employment facilitator Dice recently ranking this skill set as a “must have,” what do employer actually have in mind when they ask for Git skills? This author doesn’t believe that employers actually want people who are deeply versed in version control software — that is more or less inherent in being or becoming a developer.
What employers are really asking for is collaboration ability. To what extent are you willing to put yourself out there, with teammates and virtual teammates, and take criticism? When you write something and distribute it for analysis, you are putting your personal thoughts and abilities on display and asking for others to add to them.
This skill set, the ability to move forward as a good, positive team member is what employers really want. It’s all but certain that no one is intending to verify that you actually know how to check your code into a central repository and open it up for collaboration.
If you aren’t directly familiar with Git, don’t fret. Git is surprisingly easy to learn: you just need to create an account, watch a video tutorial, and then move forward with using it on a daily basis. Simple, right? Git may not be perfect, but it really is that straightforward to “git” started.
GitHub: Git hand in Git glove
If you know Git — meaning, essentially, that you’ve used Git — then you probably know GitHub, too. GitHub has essentially replaced every other major source code repository out there. It is quickly becoming, and in many instances has already become, the main repository for all team development environments, no matter where a given team is geographically dispersed.
Vast numbers of developers have Git experience, and a significant portion of college graduates are likely to have some familiarity with it as well. While some organizations may need to climb a modest learning curve when migrating to Git from another version control system, many of their existing and future developers do not need to be trained on Git.
In addition to the benefits of a large talent pool, the predominance of Git also means that many third-party software tools and services are already integrated with Git. This includes integrated development environments (IDEs), and tools like DVCS desktop client Sourcetree, bug-tracking software Jira, and code-hosting service Bitbucket.
If you are an inexperienced developer wanting to build up valuable skills in software development tools, then Git (and GitHub) should be at the top of your list. Just by becoming familiar with Git and working inside GitHub, you will add fluency in numerous other tools to your repertoire.
What lies ahead?
Given its ease of use and far-flung adoption among developers and managers alike, it’s not exactly surprising that GitHub would attract a corporate buyer. In June of 2018, Microsoft purchased GitHub for a tidy $7.5 billion. Corporate owner will doubtless provide a degree of stability.
It’s also a trampoline for Microsoft developers to get their hands on a million different ideas, and add a little “corporate” skin to GitHub’s grass roots feel. I leave it up to you, as the reader and as a rational tech-involved individual, to tell me whether that is a good or a bad thing.
What I do know is that if you are beginning a career as a software developer, or trying desperately to fit into a new development role, then your ability to do your work using Git and GitHub is going to be as essential as your soft skill of collaboration and getting along with your teammates. I wish you luck!