Much as professional carpenters and plumbers have certain tools in their toolbox that are indispensable … wrenches, pliers, hammers, etc, software developers have certain digital tools we simply can’t live without.
The most important tool, of course, is a programmer’s text editor, where they type in their source code. And depending on whether the programming language requires a compiler to translate the human-readable source code to the native machine language a computer can understand, the language compiler tool.
The other important tool in a programmer’s arsenal is a source control system.
A source control system is basically a database system where all source code is stored. Think of it as a digital safe deposit box. We use safe deposit boxes at banks to store personal items that need safeguarding and protection.
Source control systems are digital safe deposit boxes for source code, which is the single most valuable thing a computer programmer creates.
Without source code, you can’t make a computer do anything. Source code is the “DNA” of every software application and operating system on the planet. It defines the capabilities and functionality a software application is capable of.
Many technology companies depend on the source code which their software programmer staff generate, to help them generate revenue for the company. My own employer is no exception.
Source code is so valuable it can generate stratospheric levels of profit for a company.
It’s only natural that a company wants to ensure that the source code they have created, stays safe and sound, backed up and easily accessible by their staff of software programmers.
You could literally destroy a technology company’s ability to make money if you took away their source code. It’s that valuable. Imagine what would happen if Microsoft suddenly lost the source code to their Windows operating system and Office business software suite of applications? You would literally take away their ability to make money.
That’s why even the earliest software programmers recognized the importance and need to create a “source control system”.
A source control system guarantees there is always a “golden master copy” of the production source code that an organization has either deployed or sold to customers.
The first generation of source control systems came out all the way back in 1972.
Many other source control systems came out since then. When I started my progressional software development career back in the mid 1990s, I used Microsoft’s particular flavor of source control software called “Visual Sourcesafe”.
I distinctly remember several occasions where using Visual Sourcesafe saved my hide. Computes, just like any other machine, can occasionally break down and malfunction, which is exactly what happened to my work machines on several occasions.
But I made sure that I religiously used Visual Sourcesafe anytime I wrote new code. When my work computer went south, all my important software development work was safely backed up in Sourcesafe.
Using a source control system gives a software developer peace of mind that their work will always get safely backed up. That is the most important job of source control.
But Sourcesafe had lots of little shortcomings and problems. It often could corrupt the very source code files you wanted to have backed up. It had problems with binary files like images and data.
Probably the biggest detriment was that only one developer at a time could “check out” a given code file at one time.
The way Sourcesafe worked, was: you put your initial codebase from your local computer to the Sourcesafe database.
Then anytime you wanted to work on an existing code file, you would “check it out”.
Much like you check out a book at your local library, once something has been checked out, no one else could use the same code file and modify it while you have it checked out.
When a developer makes their code changes to a code file, you would use Sourcesafe to “check in” your local code changes, and Sourcesafe would sync up your local file changes to the master copy.
This check in/check out process was deliberately designed as a way to make sure no two developers could work on the same set of source code and accidentally overwrite each other’s changes.
It wasn’t a problem if there was only one software developer working on a particular software project, but most bigger software development projects utilize more than a single software developer. So it will be inevitable that multiple developers need to work on the same codebase.
This single user checkout system, while useful for helping to avoid code conflicts between multiple software developers working on the same codebase, also created some serious shortcomings.
The biggest being it discouraged the practice of co-development of software. If only one software developer could work on a particular code file at any given time, it practically encouraged “lone wolf” software development.
I’ve railed many times in the past about lone wolf development. The worst problem it creates is the “hit by a bus syndrome”. God forbid that something happens to the lone wolf developer working on a critical software project, the entire project instantly falls into jeopardy. Since no other developers have knowledge about how the project acts and works, there is no chance a different developer could take it over.
Linus Torvalds, the creator of the Linux operating system, decided to do something about it.
He created git, which was a radical change in the way that source control systems worked. It was a distributed source control system.
There are several major differences between a distributed and non distributed source control system.
A non distributed source control system like Visual Sourcesafe, works off the principle that there is a “master copy” of the source code for a project.
But in a distributed source control system like Git, there is no such thing as a master copy. Every developer who wants to work on the same project has their own complete copy of the project … it creates multiple “master copies” of the project.
It actually helps to create better redundancies and backups. It wasn’t uncommon for the master copy of a project stored in Microsoft’s Visual Sourcesafe system to get corrupted. If the master copy got corrupted, you were pretty much up the creek without a paddle. There was literally no way to recover from a master copy corruption of a project.
In a distributed source control system like Git, even if the copy of the project by one software developer got corrupted, other developers working on the same project were unaffected by this corruption and could continue working.
The other huge benefit to using a distributed system like Git, was you could now have as many software developers as you wanted, working on the same codebase of a project.
But how? If two developers worked on the same set of code, how would you avoid code conflicts and the danger of one developer overwriting the work of the other developer?
A distributed system like Git allows for multiple developers to work on the same set of codifies because it tracks any and all code differences between each copy of a project owned by each software developer.
So if I was working on a particular new feature that dealt with a set of code files on a project and another developer was working on a different set of features for the same set of codifies on the same project, a system like Git would allow each of us to work on our own unique set of features.
Then when I and the other developer are ready to merge our changes, Git will do a line by line comparison of our code and if it detects any sort of code conflicts, will notify the person committing the change(s) that the code conflicts must be resolved before a final code commit can happen.
Git works off the concept of code “branches”, much like the branches of a tree. Much like the trunk of a tree, a “master” branch of code represents the “golden master” version of a project that is currently what is deployed in a production environment or the software version sold to customers.
Another branch, commonly referred to as “develop”, represents all active and new development being performed on a project. This can include bug fixes and new enhancements and features to a project.
When a develop branch is deemed ready to be deployed to production or released to customers, a “release candidate” branch is created that represents all the new work.
The release candidate branch, if successfully deployed or sold to customers, will eventually get merged back into the master branch and thus reflect the new “golden master copy” of the code.
There have been many additional and useful features of distributed systems like Git that many organizations have embraced.
You can set up a system like Git to require a code review by at least one other developer who needs to look at the code written by the original software developer before that code ends up getting merged into the develop branch of a project.
This kind of code reviewing helps to avoid the “lone wolf developer syndrome” where only a single developer can know the state and functionality of an application.
Systems like Git, can also be integrated into an automated build and deployment system.
Many organizations, including my own, have set up Git so it becomes part of an overall automated system that helps to make sure code is thoroughly reviewed, tested and deployed automatically, and report any errors during the build, test or deployment process.
This helps to create higher quality software that can be released more frequently.
The best part of Git is it is also open source, so it constantly improves over time with new bug fixes and enhancements.
Git is pretty much the defect standard source control system in modern day software development, so it behooves anyone who hasn’t yet embraced it, to start learning and using it on a daily basis.
As a developer who has built my career on the Microsoft stack, it was a bit of an adjustment to move away from Microsoft’s particular set of source control systems like Sourcesafe and Team Foundation Server.
But it was definitely worth taking the time and effort to learn Git. It is a simple yet powerful source control system, and knowing how to use it effectively is a practically a requirement in most companies and IT organizations on the planet.
Git it while it’s hot!
