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.
Thus, the branching strategy is the strategy that development teams adopt when writing, linking, and deploying code when using a version control system.
Basically, it's a set of rules that developers can follow to determine how they interact with a shared codebase.
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.
The branching strategy aims to:
- Increase productivity by ensuring proper coordination between developers.
- Enable parallel development
- Help organize a series of planned and structured releases
- Map a clear path from software changes to production
- Keep the code bug free, where developers can fix issues quickly and push those changes back into production without interrupting the development workflow.
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?
- github flow
- Stream from GitLab
- trunk-based development
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:
- 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 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 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:
|The type of product and how it was released.||team size||Cooperation maturity||Applicable main branch mode|
|all||a small team||alto||Bus-based development (TBD)|
|Products that support continuous deployment and release, such as SaaS products||Half||Moderate||GitHub-Flow e TBD|
|Products with a specific release window and regular release frequency, such as iOS apps||Half||Moderate||Git-Flow and GitLab-Flow with release branching|
|Products that require product quality and ongoing deployment and release support, such as core platform products||Half||Moderate||Stream from GitLab|
|Products that require product quality and have a long maintenance cycle for release versions, such as 2B platform core products||grande||Moderate||git flow|
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.
Gitflow vs. trunk-based development
Gitflow is an alternative Git branching model that uses long-lived feature branches and multiple primary branches. Gitflow has more, longer-lived branches and larger commits than trunk-based development.
The main difference between Gitflow and trunk-based development is that the former has longer-lived branches with larger commits. Meanwhile, the latter has shorter-lived branches with fewer commits. All developers work on the main branch in trunk-based development.What is trunk-based branching strategy? ›
Trunk-based development (TBD) is a branching model for software development where developers merge every new feature, bug fix, or other code change to one central branch in the version control system. This branch is called “trunk”, “mainline”, or in Git, the “master branch”.What is the difference between branch based and trunk-based? ›
The key difference between these approaches is scope. Feature branches typically involve multiple developers and take days or even weeks of work. In contrast, branches in trunk-based development typically last no more than a few hours, with many developers merging their individual changes into trunk frequently.What are the disadvantages of Gitflow? ›
- Not suitable for continuous delivery or continuous deployment.
- Many branches to maintain. You need to remember to merge branches back into others to maintain consistency.
- Due to the overhead required to release, it can lead to a technical debt build-up.
Trunk based development is the most common branching strategy used for a microservice architecture. This is a fast workflow with minimal merging. Essentially in this model, master is the only branch which is maintained over time and other branches are considered transient and short lived.What are the three types of branching in Git? ›
There are three types of supporting branches with different intended purposes: feature, release, and hotfix.What is the difference between Gitflow and GitHub flow? ›
Git flow has branches such as Release branch, master, develop branch, hotfix branch, etc. GitHub flow is used when there is no concept of release in the application and Git flow is used mainly for verification and testing of the release branch.What problem does Gitflow solve? ›
Separates your source code's current shipping state from your next release shippable state. This is crucial for Scrum development projects where code is completed in short, shippable increments. Allows more flexibility in deciding when to release.What is the most popular branching strategy in Git? ›
Git Flow is by far the most popular Git branching strategy out there, and it's one of the oldest still in use today. It centers around having two branches: "main" and "develop." The principle behind this strategy is that all the code being developed is merged to the develop branch.
Git Flow is the most widely known branching strategy that takes a multi-branch approach to manage the source code. This approach consists of two main branches that live throughout the development lifecycle.What are the disadvantages of trunk-based? ›
With trunk-based development, bugs can creep in because full regression testing isn't done on each merge. In addition, developers need to wait for their small change to go through the automated build and test processes before merging.What are the cons of trunk-based? ›
- Conflicts. One such disadvantage is the potential for increased conflicts when multiple developers are working on the same code base. ...
- Difficult to implement. ...
- Difficult to roll back changes Finally, trunk-based development can also make it difficult to roll back changes.
Trunk-based development is a branching model that is also referred to as “mainline development.” All branches extend from one trunk/main branch, usually called the master branch. This persistent branch is where all developers commit. The master branch follows the evolution of a software project.What is the difference between Gitflow and GitLab? ›
With GitFlow, developers create a develop branch and make that the default while GitLab Flow works with the main branch right away. GitLab Flow is great when you want to maintain multiple environments and when you prefer to have a staging environment separate from the production environment.What are the advantages of Gitflow? ›
One of the key benefits of Gitflow is that it promotes a consistent release process. With feature branches, release branches, and hotfix branches, you can keep your codebase clean and organized, which is a breath of fresh air in a world where chaos is the norm.When to use gitflow? ›
Gitflow can be used for projects that have a scheduled release cycle and for the DevOps best practice of continuous delivery. This workflow doesn't add any new concepts or commands beyond what's required for the Feature Branch Workflow.What are the two recommended branching strategies? ›
Develop. Feature- to develop new features that branches off the develop branch. Release- help prepare a new production release; usually branched from the develop branch and must be merged back to both develop and master.What are the three types of branching in Devops? ›
- Trunk and release branching. Release branching creates a branch for the desired release candidate. ...
- Feature branching. Feature branching creates a branch to implement a new feature or user story in the project. ...
- Change and development branching. ...
- Fix branching. ...
- Task branching.
OneFlow consists of having only one eternal branch – “master”. In comparison to the GitFlow model, the direct difference is the absence of the “develop” branch. This approach of one long-lived branch doesn't mean that there aren't other branches involved using it.
When developing with Git flow, there are three types of supporting branches with different intended purposes: feature, release, and hotfix.What is the 3 tree architecture of Git? ›
Three-tree architecture in Git: The working directory (containing changes that may not be tracked by Git), the staging index (containing changes that are about to be committed into the repository), and the repository (being tracked by Git).What is one rule of GitHub flow? ›
Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable.What are the major steps in the GitHub flow? ›
- Create a branch. Create a branch in your repository. ...
- Make changes. On your branch, make any desired changes to the repository. ...
- Create a pull request. Create a pull request to ask collaborators for feedback on your changes. ...
- Address review comments. ...
- Merge your pull request. ...
- Delete your branch.
GitHub flow is a lightweight, branch-based workflow that supports teams and projects that deploy regularly. You can adopt the GitHub flow method to standardize how your team functions and collaborates on GitHub. For more information, see "GitHub flow."Why do you prefer trunk-based development? ›
Trunk-based development, done in a disciplined way, streamlines the development process, enhances team collaboration, improves code stability, supports efficient CI/CD practices, and may result in less technical debt.What is the difference between trunk-based and GitOps? ›
Branch-based GitOps for your infrastructure requires you to maintain multiple branches at all times. This ultimately leads to drift and confusion of what is your source of truth. With trunk-based, only a single branch acts as the source of truth and only one branch is ever maintained.How do I implement trunk-based development in GitHub? ›
- You check out a new branch from the main branch.
- You commit your code on this branch and push it to the GitHub repo.
- You open a Pull Request (or Merge Request as GitLab calls it).
- Automated tests verify that the application behaves as expected.
There are two major types of shoot branching: lateral (axillary), which involves the formation of a primordial bud in the organogenic zone of the apex, and terminal (dichotomous), which is an outcome of the meristem bifurcation.Which is the most basic type of branching statement? ›
This is the most simple form of the branching statements. It takes an expression in parenthesis and an statement or block of statements. if the expression is true then the statement or block of statements gets executed otherwise these statements are skipped.
I normally prefer git pull --rebase . When you run git pull --rebase, your current local branch gets rebased on top of the last commit from the upstream . This will help you to achieve a linear history of changes. When you do git pull -ff may result in a non-linear histories, by creating merge commits.Does Google use trunk based development? ›
In a trunk-based workflow, only a single branch (trunk) holds the project's deployable code, whereas a feature-based workflow uses many long-lived branches for developing individual features. Teams at Facebook, Google, Netflix, and many other tech businesses use these workflows.What is the best way to merge branches in git? ›
To merge branches locally, use git checkout to switch to the branch you want to merge into. This branch is typically the main branch. Next, use git merge and specify the name of the other branch to bring into this branch. This example merges the jeff/feature1 branch into the main branch.What is Gitflow workflow? ›
The Gitflow Workflow defines a strict branching model designed around the project release. This workflow doesn't add any new concepts or commands beyond what's required for the Feature Branch Workflow. Instead, it assigns very specific roles to different branches and defines how and when they should interact.What is the point of a trunk? ›
The trunk is useful area, with purpose to ensure comfort when transporting luggage and loads.What is the purpose of trunk? ›
A trunk provides network access between two points. They often connect switching centres in a communication solution.What are the benefits of using a trunk link? ›
Trunking can allow a telecommunication or data network to expand its bandwidth and capabilities. This kind of network allows multiple users to make a link with the same network node. The structure can enable the network to better manage and direct traffic, preventing congestion that slows down data processing.What is the difference between trunk and branch of a tree? ›
Trunk: The main structure of the tree from which branches grow. Branch: A part of the tree that grows from the trunk in a typically horizontal, upward direction.Is trunk based development safe? ›
Trunk-based development – Teams should integrate code quickly, at least once daily, or ideally upon commit, and all teams should work off a single trunk, avoiding long-lived branches. Gated commit – Committing to the main trunk is risky, as broken changes can impact many teams.What is trunk in trunk based development livery? ›
The trunk is the sole repository for code development. Direct-to-trunk commits encompass code designed to create or publish artifacts. Long-lived feature branches play little to no role. A DevOps team may deploy short-lived feature branches to address issues caught during code review.
GitHub took action based on the Conservancy's suggestion and moved away from the term master when a Git repository is initialized, "We support and encourage projects to switch to branch names that are meaningful and inclusive, and we'll be adding features to Git to make it even easier to use a different default for new ...Does trunk based development use pull requests? ›
The developer creates a pull request, to the trunk branch. With this pull request, they include a git tag that identifies their changes. A developer reviews their code and verifies the fix, so they approve the pull request. The developer merges the code to trunk and verifies that it works in an integration environment.Is trunk-based development good? ›
A trunk-based development workflow is a good fit for many applications. If you are working on a new project that is either a minimum viable product or a proof of concept, then the trunk-based workflow is likely the way to go.Which branching strategy is best? ›
A good branching strategy should have the following characteristics: Provides a clear path for the development process from initial changes to production. Allows users to create workflows that lead to structured releases. Enables parallel development.Does Netflix use trunk-based development? ›
Two of the most widely used workflows are feature-based and trunk-based development (aka TBD). Software development teams at Netflix, Google, Facebook, and other tech giants use these workflows.What is the disadvantage of trunk-based development? ›
- Conflicts. One such disadvantage is the potential for increased conflicts when multiple developers are working on the same code base. ...
- Difficult to implement. ...
- Difficult to roll back changes Finally, trunk-based development can also make it difficult to roll back changes.
Git flow has branches such as Release branch, master, develop branch, hotfix branch, etc. GitHub flow is used when there is no concept of release in the application and Git flow is used mainly for verification and testing of the release branch.Why not trunk-based development? ›
One of the main challenges with trunk-based development is contention collision. If too many people are checking their changes into the mainline at the same time, it will be in a constant state of churn. Developers can end up tripping over each other and constantly breaking builds.What are the benefits of Gitflow? ›
One of the key benefits of Gitflow is that it promotes a consistent release process. With feature branches, release branches, and hotfix branches, you can keep your codebase clean and organized, which is a breath of fresh air in a world where chaos is the norm.What is the opposite of trunk-based development? ›
Mainline is diametrically opposite to Trunk-Based Development - do not do this. Mainline is a branching model that was promoted for ClearCase implementations. It is the principal branching model that Trunk-Based Development opposes.
The developer creates a pull request, to the trunk branch. With this pull request, they include a git tag that identifies their changes. A developer reviews their code and verifies the fix, so they approve the pull request. The developer merges the code to trunk and verifies that it works in an integration environment.