Git

For Agile teams, Git is the reliable version control system and a significant part of a DevOps toolset.

What is Git in simple words? This open-source project actively supports a range of workflows that suit the needs of any Agile software development team.

The distributed nature of Git gives it excellent performance characteristics. They provide Agile developers with the freedom to experiment locally and publish their changes only when they are ready for distribution to the team.

What is the purpose of Git? What are the Git advantages? What are the types of branches in Git, and how should you use them? You probably have even more questions. This post aims to give you all the answers and clarify controversial points. Let’s dive in!

What Is Git?

If you are searching for the most widely used modern version control system over the globe, this is definitely Git. Git is an actively maintained open source project originally developed in 2005 by Linus Torvalds, the creator of the Linux kernel.

Numerous software projects rely on Git for version control. This includes commercial projects and open source as well. Developers who have experience working with Git are widely represented in the pool of available software development talents. Git has a distributed architecture; it is an example of a Distributed Version Control System (DVCS).

Rather than have only one place for the full version history of the software, in Git, every developer’s working code copy is also a repository that may include the full history of all changes. It is worth adding that Git was designed with performance, flexibility, and security in mind.

Why Git?

Nowadays, many developers prefer Git above all other tools around. Git can really change the way developers think of merging and branching. With Git, merging/branching is extremely simple and cheap. They are considered one of the core parts of the daily workflow.

Because of its simplicity and repetitive nature, branching and merging are no longer something scary. Version control tools are aimed to assist in branching/merging more than anything else.

What are the origins of Git?

Git began with fiery controversy and creative destruction. The Linux kernel has a fairly large scope. For most of the lifetime of this open-source software project maintenance (1991–2002), changes to the software were passed around as patches and archived files.

In 2002, BitKeeper – a proprietary DVCS was what the Linux kernel project began to use.

In 2005, warm relationships between the company that developed BitKeeper and the community that developed the Linux kernel broke down. The free-of-charge status of the tool was revoked.

This situation prompted the Linux community to create their own tool based on the lessons they learned while using BitKeeper. The new system had the following goals:

• Simple design
• Advanced speed
• Strong support for non-linear development
• Ability to handle large projects like the Linux kernel efficiently
• Fully distributed

So, 2005 was the year of Git’s birth. Since that time, Git has evolved and matured but yet retains the initial qualities. It’s really fast, efficient with large projects, and provides an excellent branching system for non-linear development.

Three states of Git

This is the most important thing to remember about Git if you want the rest of the learning process to run smoothly. Git has three main states that your files can be in: modified, staged, and committed.

• Modified files consist of files that have changed but have not yet been committed.
• A Staged file is a modified file in its current version, marked for inclusion in the next commit.
• Committed files mean that the files are already saved in your local database.

Git Basics: Repositories, Branches, and Commits

In order to see Git in practice, you should dive into some basic terms in short words.

A location where your code is stored is a Repository. In fact, this is a folder on your machine that contains your project code. After turning this folder into a Git Repository, Git manages the project code version history.

However, the code is not directly stored in the Repository. Inside the Repository, you have Branches (subfolders). After you add the first code to the Repository, a default Main Branch is created. You are not limited to one Branch as the Repository usually has multiple Branches.

However, the question is: Where do you store your code? Inside the Branches is the answer. Branches contain different code versions — your Commits. Every single Commit is a snapshot of a specific version of the code.

Introducing the Git Flow Workflow

There are 5  branch types in the Git flow workflow:

• Main
• Develop

Supporting branches:

• Feature
• Release
• Hotfix

1. Main Branch

The main branch is typically referred to as “master” but nowadays this term looks outdated, and it’s better to use the “main” term instead.

Containing production-ready code that can be released is the key goal of the main branch in the Git flow workflow.

The main branch is created at the start of a project. It is maintained throughout the development process. It can be tagged at different commits to signify different versions or releases of the code. The other branches will be merged into the main branch after they have been competently tested.

2. Develop Branch

The Develop branch in Git workflow is created at the start of a project. It is maintained throughout the development process and includes pre-production code with newly developed features that are in the testing process.

The features that are newly created should be based on the Develop branch. Then they should be merged back in when ready for testing.

Git flow development also contains three types of supporting branches with their specific purposes: feature, release, and hotfix branches.

3. Feature Branch

This is the most common type of branch in the Git flow workflow. You’ll need the Feature Branch when adding new features to the code.

You will start this branch off the develop branch when working on a new feature. Then you’ll merge your changes back into the develop branch when the feature is completed and thoroughly reviewed.

4. Release Branch

It should be used when preparing new product releases. The work being performed on Release Branches concerns finishing touches and minor bugs. They relate to new code that should be considered separately from the main Develop Branch.

5. Hotfix Branch

The Hotfix Branch is applied to quickly address necessary changes in the Main Branch.

The Main Branch is the base of the Hotfix Branch. It should be merged back into both the Main and Develop Branches. Merging the changes from the Hotfix Branch back into the Develop Branch is critical. This ensures that the fix persists the next time the Main Branch is released.

What are the benefits of using Git?

• Performance. Git is about great performance when it comes to version control systems. Branching, merging, and committing are well optimized for a better performance than other systems.
• The branching model. It allows having multiple local branches which are independent of each other. This enables you to have friction-less context switching, role-based code, and disposable experimentation.
• Security. Git handles your security with a special algorithm that manages your versions, files, and directory securely.
• Distributed in nature. It means that the repository or the complete code base is mirrored onto the developer’s system (meaning that he/she can work on it only).
• Staging area. There is an intermediate stage called “index” in Git (also known as “staging area”) where commits can be modified before completing the commit.
• Open-source. The open-source nature invites developers to contribute to the software and make it more robust and reliable through the features and additional plugins.

Three Tips to Succeed

1. Think about tasks as Git Branches

When you know all the features, when they are added to a product roadmap, and the development team is ready, then Git may come into play.

Product, Quality Assurance, design, and engineering teams hold a feature kick-off meeting to get a shared understanding of what a feature will be. So, the project scope defines what tasks the feature needs to be broken down into before the team can complete it. These tasks (user stories) are then assigned to individual developers.

Here Git starts to fit up into your Agile workflow. Branching is straightforward. It allows teams to easily collaborate inside one codebase. While creating a branch, developers have their own isolated version of the codebase which they can change.

2. Take the advantage of testing multiple branches individually

When branches are ready for code reviews, Git plays another key role in an Agile development workflow – testing.

Effective Agile and DevOps teams practice code reviews and apply automated tests. Developers can easily notify their teams that the branch work is ready for review.  A pull request is a way to ask another developer to merge one of your branches into the Main Branch and that it is ready for testing.

3. Get transparency and quality to Agile development

If you want Git to work perfectly for your Agile workflow, make sure that your Main is always green. In case a feature isn’t ready, then wait for the next release. This will not be actually a big deal if you practice shorter release cycles.

To sum up

For many, this branching model has nothing shocking new. However, the “big picture” figure may turn out to be tremendously useful in your projects. It forms an elegant model that is easy to comprehend. It allows team members to develop a shared understanding of the branching and releasing processes.

Now you know all the basics of Git, so go ahead and explore it closely in practice!