What is Git?

Git is a free and open-source distributed version control system designed to handle everything from small to massive projects with speed and efficiency. It was created by Linus Torvalds in 2005 to support the development of the Linux kernel. Git facilitates collaboration among developers by allowing them to track changes in source code during software development, enabling multiple developers to work on different parts of a project simultaneously.

Branching is one of the key features. Git allows developers to create branches, enabling them to work on new features or fixes independently from the main project (usually in the “master” branch). Once the work on a branch is completed, it can be merged back into the main branch or another branch.

Git Branch Strategy

Without clear standards for branch management, you may find yourself flooded with questions like “What was the purpose of creating this branch?”, “From which commit did this branch diverge?”, “Which branch should I branch off from?”, “Where should my branch be merged into?”, “Which branch is the latest?”, “Which branch is the deployed version?” Such uncertainties can lead to chaos within the project.

Git branching strategies are workflows designed to effectively manage the Git branches of a project. While you could create your own branching strategy, there are best practices established in the industry for effective branch management. This post introduces two popular practices: Git Flow and GitHub Flow.

Git Flow

Git Flow is a branching strategy that became popular following a blog post titled “A successful Git branching model” by Vincent Driessen in 2010.

Git Flow categorizes branches into three main types: Main, Develop, and Supporting branches, with the latter further divided into Feature, Release, and Hotfix branches.

The Main and Develop branches are maintained throughout the development process. In contrast, supporting branches are created as needed and deleted once their role is completed, enabling parallel workflow within the team. Let’s examine each type:

• Main Branch

The Main branch stores the official release history. It is created at the start of the project and maintained throughout the development process. Each deployed version is marked using tags.

• Develop Branch

This branch serves as an integration branch for features. Once development is completed, it merges into the Main branch.

• Feature Branch

A Feature branch is used for developing a single feature. It branches off from and merges back into the Develop branch upon completion. Merging should create a Merge Commit rather than using Fast-Forward to ensure history is grouped by feature. These branches are named in the format feature/branch-name.

• Release Branch

The Release branch is for preparing software deployment. It branches off from the Develop branch for minor edits or pre-deployment bug fixes. Once ready, it merges into both Main and Develop branches, with the Main branch version marked using tags. This separation allows other team members to continue developing features in parallel without being involved in the deployment process. These branches are named like release/v1.1.

• Hotfix Branch

If an issue arises in a deployed version, a Hotfix branch is used for the fix. It branches off from the Main branch and, once the issue is resolved, merges back into both Main and Develop branches. This allows the team to continue feature development in parallel without being sidetracked by the hotfix. Hotfix branches are named in the format hotfix/v1.0.1.

The Limits of Git Flow: Not Suitable for Web Applications

Vincent Driessen, after a decade since publishing “A successful Git branching model” in 2010, penned a reflective note in 2020 atop his original post. Here’s a summary of his reflections:

„This model was conceived in 2010, now more than 10 years ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model laid out in this article) has become hugely popular in many a software team to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

During those 10 years, Git itself has taken the world by storm, and the most popular type of software that is being developed with Git is shifting more towards web apps — at least in my filter bubble. Web apps are typically continuously delivered, not rolled back, and you don’t have to support multiple versions of the software running in the wild.

This is not the class of software that I had in mind when I wrote the blog post 10 years ago. If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.“

Git Flow is particularly suited for projects where explicit version management is necessary, such as smartphone applications, open-source libraries/frameworks, and the like.

Web applications, by their nature, typically only present the latest version to users, eliminating the need for supporting multiple parallel versions. Additionally, web applications can be released multiple times a day. Given these characteristics, Git Flow may not be the most appropriate for web application development.

Github flow

GitHub Flow is a simple yet effective branch management strategy used in software development. Developed by GitHub, it is particularly designed to fit continuous deployment environments, aiming to streamline the development process to facilitate fast and continuous software releases.

• Main branch: similar to GitFlow the main branch. This branch contains the release version of the code.
• Feature branch: developers branch directly from the main branch to work on new features.

The key steps of GitHub Flow include:

1. Create a Branch

When adding a new feature, create a feature branch from the main branch. Name the branch in a short and clear manner to indicate the feature it’s addressing, allowing fellow collaborators to understand its purpose at a glance.

2. Make changes

Proceed with making changes or adding new features in the newly created branch. This branch doesn’t affect other repositories, so you have the flexibility to revert changes or make further adjustments if mistakes occur. Commit and push your changes. This allows for backing up your work on remote storage and enables other collaborators to review and contribute to the changes.

3. Create a Pull Request

To receive feedback on your changes, you can create a PR (Pull Request). This process allows you to receive reviews on your changes from other collaborators. Additionally, you can make review approvals mandatory before merging into the main branch.

4. Merge the Pull Request

Once the PR is approved, you can merge it into the main branch. Even after merging, the commit history is preserved to help future contributors understand the changes.

The advantage of GitHub Flow lies in its simplicity. Unlike complex branching strategies, GitHub Flow ensures that only code ready for deployment is merged into the main branch, keeping the code in the main branch always in a deployable state. This approach is ideal for rapidly evolving projects and small teams.