Git for Managers: A Plain-English Overview | Blaazin Software Consulting, Inc. Barrie

Overview

This document is intended to give Non Software Developers an in-depth idea of what Git is, and what it can do. This document is NOT intended as a How-To guide. You can find this on our website at https://blaazinsoftware.com

What is Git?

Officially, Git is a distributed Version Control System (VCS). We’ll get to the distributed piece later, but as with all Version Control Systems, Git keeps track of the history of files as they change over time. What sets Git apart is what it stores and what it can do with the history, as well as the aforementioned distribution.

What are the basic features of Git?

When Git is initialized on a server (or virtual instance), it is empty, and represents a blank section of a file / folder system. Folders and files of any type can be committed into the Git repository, but Git really excels at handling text-based files. The reason for this is that Git keeps track of the changes to the text file line by line, and even character by character.

Committing

Every time changes to one or more files are committed to the repository, Git assigns that commit a number which is called a Revision number. Git can then use this (or any) Revision to Revert back to should it be requested, or perform comparison operations (more on this later). History of these commits is very important to Git (and to you), so remember that the repository stores information on each and every commit. This information includes (but is not limited to) the changes to each file. I stress that Git stores the changes because Git does not store a copy of each revision of each file. This would cause the repository to become too large to manage. Plus, what you really care about is the changes to each file over time, and when you need a version of a file, you can get it easily.

Tagging

Tagging is a common feature among VCS applications, and Git is no exception. A tag is effectively a branch and is typically taken to represent a release point (v0.1, v0.2, v1.0, etc.). Once a tag is created, it is usually left alone unless a Hotfix is needed. In this case, the tag can be used to create a branch from as a starting point to address the issue. It is a general rule that under no circumstances would a tag be modified directly once it is created. As this represents a version of your application that has been released to your customers, it is the only way to know exactly what they have.

Branching

As with most VCS applications, Git supports Branching. A branch is a logical copy of the history of your repository. Once a branch is created, any commits done to it are kept separate to that branch. This allows for any number of commits to be kept separate from the original version, and does not affect the original version in any way (until and unless you want it to). Branches can be named (to be able to be found later), committed to, deleted, or merged with - or into - another branch of the repository (like the master branch).

Merging

Merging is the start to what really sets Git apart. Typical VCS applications attempt to merge the differences of each file together, and while not bad, this does lead to a lot of conflicts. As a result, organizations who use typical VCS applications tend not to branch very often. Instead of merging the differences of each file, Git looks into its history to find the most recent common ancestor of the two branches in the merge. With that information, Git applies each commit from the source branch into the target branch one at a time. This leads to a lot less conflicts, and is done in the blink of an eye. For these reasons, organizations who use Git tend to do a lot more branching and merging.

C’Mon, All VCS Products are the Same! (False)

In non-distributed VCS applications every person usually works on their machine, and commits directly to the central repository. While this has worked well in a lot of cases, it is far from ideal. As branches are typically not created, each person works on files outside of the repository. As people are all committing directly into the same main branch in the repository, this branch is frequently broken (from a testing perspective), and takes time to fix. Plus, as the repository is on a central server, to commit requires this person to be connected to the server. Also, if someone has to switch what they are doing to work on a different issue (i.e. because a high-priority issue has been discovered), this person only has three options:

Revert their local changes and lose what they have done
Work on the new issue and hope they can keep the changes separate from each other
Create a completely new folder in a separate location in their file structure

This means they have to re-download the files from the central VCS location, and set up their new project / folder in the new location, and they will have to manually merge these changes back into the other copy of the folder I have personally done all three at one time or another, and it's tough to pick which one is more painful. Suffice it to say, they all take time, and none are close to ideal.

But What Makes Git so Great?

One of the main things that sets Git apart is the fact that it is distributed. That means that a full copy of the history is distributed to all copies of the repository on whichever server instances (or Developer machine) the repository has been cloned to. What this means is that any repository can have branches made, be committed to, and push and pull branches to and from any other repository. As well, commits and branches can be made locally without the need to be connected to any server of any kind. So a person can create any number of new branches locally, commit any number of changes, switch to a new branch without effecting the others, and push to the original repository when ready. This comes in particularly helpful when flying into the Clients’ site (no network connectivity required on the airplane)!

I can’t tell you how many times I have been working on a feature when a high-priority issue is discovered. So, I have had to put on hold what I was working on, and switch to the new issue. With Git, Developers can commit the changes to the feature locally, create a fresh branch from master (which does NOT contain the changes for the feature), fix and commit the changes for the new issue, then re-open the branch to continue working on the feature. This saves a HUGE amount of hassle, and time.

A branch can also be shared by many people as well. This allows any number of people to be working on a feature in a Git branch that is separate from the master code base. Only if and when (if ever) it is ready is it merged back into master. I have worked on numerous projects over the years that were never intended to be put into the master code base (mostly Proof of Concepts). This work was usually done with other people, and Git allows for this seamlessly. All of us on the team were free to make changes, commit, and interact changes from other people: all while working in Git, and not effecting the main code base. In some cases, it was decided that these POCs would be integrated into the main application, and all that was required was to merge this POC branch into master (which took roughly 10 seconds).

So where does all this leave us?

Although using Git in a distributed way does require committing locally, then pushing to the main repository (which is an extra step than traditional VCS applications), Git handles the branching, pushing, and merging almost seamlessly. Any one of the differences that Git offers (seamless branching / merging, distributed architecture, etc) would be reason enough to switch to Git. Put them all together, and Git provides a powerful backbone to any new or existing piece of software.