An Overview of Git

What is git?

Git is one of the most popular and widely known version control tools. It's been used for countless open-source projects, commercial products, and even for non-coding projects like to write books. Git keeps track of changes to you code (or other content) and allows you to create incremental versions, as well as keep a history of changes. You can even roll back to previous versions or "cherry pick" parts of previous versions you want to bring back. 

How does git work?

Git was intended to be a serverless system, but most setups today have a central server (repository) often known as "origin". Origin is typically where the "master" code is stored (more on this later). Contributors (developers, designers, writers, etc) typically create a copy of this code, known as a branch, for working on. The contributor has an instance of git installed on their own computer that has its own local database. They use their local instance of git to copy (clone) their newly created branch of code to their own computer. They use whatever tools they prefer to make changes to the files in their branch. When they are finished, they "stage" these changes to tell git to track them and "commit" so that git records the changes in it's local database. Once they've made all of the changes they want, they can "push" the code to origin to store what they've done in the central repository. Take a look at the graphic below for an illustration of this process.

Once all of the desired changes have been made on a branch, that branch can be merged into the master branch. Remember that git tracks changes within files, not just files. When a contributor merges a branch to another branch, the changes the contributor made to their branch are made to the other branch. This allows contributors to work on different parts of a project at the same time and commit changes to the project without stepping on work other contributors have done. It's confusing, I know. Below is an example of my favorite branching strategy that will hopefully help clear it up.

Branching Strategies

There are a lot of different branching strategies used in git (and other version control tools). Here, I will show you my favorite one using an example. Use the diagram below to follow along. Let's suppose we have Carl and Mary both working at Awesome Inc. They are developers working on the flagship product: Awesome Software. On the left, you'll see there is a "Master branch". This is the master copy of the code. The blue dots represent releases (e.g. version 1, version 2, etc.). Here is what happens:

1. The project manager creates a development branch from the master branch. At first, the development branch is an exact copy of the master branch. Changes are not made directly to the development branch, all changes happen in "feature" or "bug fix" branches.
2. Carl is going to add a feature to the project, so he creates a new branch, known as a "feature branch" from the development branch. Feature branches are typically short lived. Carl finishes his changes, but before they can be merged into the development branch, they must go through a "code review" where other developers on his team look at his code and either approve or disapprove it. If it gets disapproved, Carl goes back and refines his changes. Once approved, he can merge his code into the development branch.
3. Mary is fixing a bug in the code. She also creates a new branch, known as a "bug fix" branch, from the development branch. Like feature branches, bug fix branches are typically short lived and address only the bug they are created to fix. Mary's code goes through the same code review approval/disapproval process that Carl's code went through. Once approved, she merges her code into the development branch.
4. Testing is a major part of development. Often unit tests are included in the feature and bug fix branches. The development branch is also frequently tested, usually automatically (a topic for another day).
5. There are typically dozens or even hundreds of feature branches and bug fix branches merged into a development branch before it is considered ready to be released as a new product version. The development branch also undergoes extensive testing and review (the people who do this testing and review depend on the organization). At the bottom of the diagram you will see a light blue dot labeled "New version release". Once the testers and reviewers are satisfied, the development branch is merged with the master branch. At that point, a new version of Awesome Software is created from the master branch and released to customers. Notice the development branch is kept. Development continues on this branch to produce future releases.

This is just one example of a branching strategy and you will likely encounter others, some simpler and some much more complex. This one just happens to be my favorite.

Using version control is hugely beneficial to development projects, especially larger ones with multiple developers. If you use a suite like GitLab, you can even build automatic testing and deployment into your version control process, leaving you more time for coding and making releases easier. It is definitely worth learning. In a future post, I'll go through the basic workflow of using git with a project.