Git branching strategies: GitFlow, Github Flow, Trunk Based... (2023)

In modern software developmentspeed and agility are key when it comes to software development and release. However, when you have a large team of developers working concurrently, forking and merging code can quickly turn into a disaster.

Therefore, teams must have a process for implementing many changes at once. This is where having an effective branching strategy becomes a priority for these teams.

What is a branching strategy?

Branches are primarily used by teams to develop features, giving them a separate workspace for their code. These branches are usually merged back into the main branch when the job is complete. This way, features (and fixes and bugs) are separated from each other, making it easier to fix bugs.

This means that branches protect the main line of code, and any changes made to a branch do not affect other developers.

Such a strategy is necessary because it helps to keep the repositories organized to avoid errors in the application.scary combination when multiple developers work simultaneously and all add their changes at the same time.

These merge conflicts would ultimately discourage shipping code and therefore prevent creating and maintaining an efficient DevOps process as an overall goal.DevOpscreates a fast workflow that lets you release small batches of code.

Therefore, following a forking strategy will help resolve this issue so that developers can collaborate without stepping on each other. In other words, it allows teams to work in parallel for faster releases and less conflicts, creating a transparent process when making changes in source control.

When we talk about branches, we mean separate lines of code that branch off the main branch, allowing developers to work independently before merging their changes back into the codebase.

In this post, we'll describe some of the branching strategies that teams use to organize their workflow, discuss their pros and cons, and which strategy you should choose based on your needs, goals, and team capabilities.

Why You Need a Branching Strategy

As mentioned above, it is necessary to have a branching strategy to avoid merge conflicts and allow changes to be more easily merged into the main trunk.

Ramos Git

Branches are not only available in Git. However, in this article, we're going to focus on Git because of the many advantages this branching model offers.

So, before we dive into different branching strategies, including Git's branching strategies, let's take a look at how Git actually handles branching and why it stands out from other VCS tools.

just put,Git and other version control tools allow developers to track, manage and organize their code.

Git branches allow developers to move away from the main branch by creating separate branches to isolate code changes. The default branch in Git is the master branch.

The biggest advantage of a Git branch is that it is "lightweight", meaning that the data consists of a series of snapshots; therefore, with each commit, Git takes a snapshot of what your files looked like at that point in time and stores a reference. for that snapshot. This means that these branches are not just copies of the filesystem, but simply a pointer to the last commit.

Meanwhile, other VCS tools store information as a file-based changelist, which can slow things down and take up a significant amount of space.

In Git, a branch is basically a reference or pointer to the last commit in a given context; this is not a commit container. When you create new commits on a new branch, Git creates new pointers to track the changes. Therefore, Git branches can be seen as a pointer to a snapshot of your changes.

The images below illustrate this concept, where the top image shows the master branch and a pointer pointing to the last commit, and the image just below shows what happens when you create a new branch called "dev": the new pointer now points to the last appointment.

To sum up,Git's branching model is lightweight compared to other version control systems; That's why it's so easy and cheap to create branches in Git,because you don't need to copy all the code to the branch, creating a lot of duplicate files, unlike other VCS tools.

What are typical Git branching strategies?

GitFlow

Considered a bit complicated and advanced for many of today's designs,GitFlowenables parallel development where developers can work independently from the master branch on features where a feature branch is created from the master branch.

Then, when the changes are complete, the developer merges those changes back into the main branch for publishing.

This branching strategy consists of the following branches:

• Host
• To develop
• Feature – To develop new features derived from the development branch.
• Launch: assistance in preparing a new production launch; it usually branches off from the development branch and needs to be merged back together for development and mastering
• Patch: It also helps you prepare for the release, but unlike release branches, patch branches are the result of a detected bug and need to be fixed; allows developers to continue working on their own changes in the development branch while the bug is fixed.

The master and development branches are considered to be master branches with an infinite lifetime, while the others are smaller branches intended to support parallel development between developers, usually of short duration.

Pros and Cons of GitFlow

Perhaps the most obvious advantage of this model is that it allows for parallel development to protect production code, so that the master branch remains stable until release while developers work on separate branches.

Furthermore, the different types of branches make it easier for developers to organize their work. This strategy has simple, separate branches for specific purposes, although it can get complicated in many use cases because of this.

It's also great for handling multiple versions of production code.

However, as more branches are added, they can become difficult to manage as developers merge their changes from the development branch into the master branch. Developers will first need to create a release branch and then make sure any final work is merged back into the development branch, then that release branch will need to be merged back into the main branch.

If changes are tested and the test fails, it becomes increasingly difficult to determine exactly where the problem lies, as developers get lost in a sea of ​​commits.

In fact, due to the complexity of GitFlow, this can slow down the development process and release cycle. In that sense, GitFlow is not an effective approach for teams looking to implement continuous integration and continuous delivery.

So a much simpler workflow like GitHub Flow is recommended in this case.

github flow

github flowEsa simpler alternative to GitFlow, ideal for smaller teams as they don't need to manage multiple versions.

Unlike GitFlow, this template does not have a release branch. It starts with the master branch, then developers create branches, feature branches that branch directly from the master branch to isolate their work, which is then merged back into master. The feature branch is then deleted.

The main idea behind this model is to keep the core code in a constant deployment state so that it can support continuous integration and continuous delivery processes.

More and less GitHub Flow

Github Flow focuses on agile principles, so it's a streamlined and fast branching strategy with short production cycles and frequent releases.

This strategy also allows for quick feedback loops so teams can quickly identify and resolve issues.

Because there is no development branch, because you test and automate changes in a branch, allowing for rapid and continuous deployment.

This strategy is particularly suitable for small teams and web applications, and is ideal when you need to maintain a single production version.

Therefore, this strategy is not suitable for dealing with multiple versions of code.

Furthermore, the lack of development branches makes this strategy more prone to bugs, which can lead to instability in production code if branches are not properly tested before merging in preparation for a major release and bugs are fixed in that release. . As a result, the master branch can become more easily confused, as it serves as both a production and development branch.

Another downside is that this model is best suited for small teams and consequently as teams grow there can be merge conflicts as everyone is merged into the same branch and the lack of transparency means that developers cannot see into what the other developers are working.

Stream from GitLab

Stream from GitLabis a simpler alternative to GitFlow that combines feature-based development and feature forking with issue tracking.

With GitFlow, developers create a development branch and make it the default, while GitLab Flow works directly with the master branch.

GitLab Flow is great when you want to maintain multiple environments and when you prefer to have onestage atmosphereseparate from the production environment. Then, when the main branch is ready to be deployed, you can link it back to the production branch and download it.

Therefore, this strategy provides adequate isolation between environments, allowing developers to maintain multiple versions of software in different environments.

While GitHub Flow assumes you can deploy to production whenever you merge a feature branch into a master, GitLab Flow attempts to address this by allowing code to pass through internal environments before hitting production, as shown in the image below.

Therefore, this method is appropriate in situations where you don't control release timing, such as an iOS app that needs to be reviewed first in the app store, or when you have specific deployment windows.

trunk-based development

trunk-based developmentit's a branching strategy that doesn't actually require branching; instead, developers push their changes to a shared trunk at least once a day. That shared broadband should be ready to roll out at any moment.

The main idea behind this strategy is that developers are more likely to make small changes, so the goal is to reduce long-running branches and avoid merge conflicts since all developers work on the same branch. In other words, developers push changes directly to trunk without using branches.

Therefore, trunk-based development is a key enabler.continuous integration (CI) and continuous delivery (CD)since changes are made more frequently to the trunk, many times a day (CI), allowing resources to be released much faster (CD).

This strategy is often combined withfunction flags. Since the bus is always ready for release, feature flags help decouple implementation from release, so any changes that aren't ready can be wrapped in a feature flag and hidden, while entire features can be hidden. be available to end users immediately.

Pros and cons of bus-based development

As we have seen, bus-oriented development paves the way for continuous integration, as the bus is constantly being updated.

It also improves collaboration, as developers have better visibility into changes made by other developers, as commits are pushed directly to the bus without the need for branches. This differs from other forking methods, where each developer works independently on their own branch, and any changes that occur in that branch can only be seen after merging with the main branch.

Since trunk-based development does not require forking, it removes the stress of long-running forks and therefore merge conflicts or so-called "merge hell" as developers are much more likely to make small changes. This also facilitates the resolution of possible conflicts.

Ultimately, this strategy allows for faster releases because the common link is kept in a constant release state and a continuous workflow is built into the link, resulting in a more stable release.

However, this strategy is suitable for senior developers as it offers a lot of autonomy, which may discourage inexperienced developers as they directly interact with the shared link. Therefore, for a junior team whose work you need to closely monitor, you might choose a Git branching strategy.

How to choose the best branching strategy for your team

When you're starting out, it's best to keep it simple, so development based on GitHub Flow or Trunk might work better initially. They are also ideal for smaller teams that only need to maintain a single version of a release.

GitFlow is great for open source projects that require tight control over access to changes. This is especially important because open source projects allow anyone to contribute, and with Git Flow you can see what is being put into source code.

However, GitFlow, as mentioned above, is not suitable for DevOps deployments. In this case, the other strategies discussed are better suited for the Agile DevOps process and forCI and CD pipeline support.

followingtablesummarizes the strategies discussed in this article and which strategy is appropriate in which context:

In conclusion, there is no perfect strategy. The chosen strategy will depend on the team and the nature and complexity of the project, so it should be evaluated on a case-by-case basis.

It's also a good idea to start with a strategy and adjust it to your needs over time. It goes without saying that whichever strategy you choose, you should aim to increase your team's productivity by providing them with a clear and consistent workflow strategy.