[git, github, branching, strategies, trunk-based development, feature branching, git flow, branch, branches]


A Git branching strategy allows developers to collaborate on a project while also tracking changes and maintaining multiple versions of the codebase. There are several Git branching strategies available, each with its own set of advantages and disadvantages. The best strategy is determined by the project’s and team’s unique requirements. In this topic, we’ll go over three popular Git branching strategies:

  1. Trunk-Based Development
  2. Feature Branching
  3. Git Flow

Strategy 1: Trunk-Based Development

What is Trunk-Based Development?

Trunk-based development (TBD) is a branching strategy in which all developers make changes directly on the main branch, commonly referred to as the trunk, which holds the project’s deployable code. Developers are encouraged to commit frequently and use feature toggles* and other techniques to manage changes that are not yet ready for release. Testing is typically automated, with a focus on continuous integration (CI) and continuous delivery (CD) to ensure that code changes are thoroughly tested before they are deployed.

If a coding task requires an extended duration, possibly spanning over several days, the developer may create a branch from the main codebase, implement the necessary changes, and then merge it back into the main codebase once development is complete. However, the goal of trunk-based development is to minimize the use of feature branches and encourage developers to work collaboratively on the main codebase as much as possible.

*Feature toggle

Feature toggles, also known as feature flags, can be used in software development to manage features that are not yet ready for release or that need to be shown only to specific users or groups. They function like a switch that can be turned on or off to enable or disable a particular feature in the codebase.

Trunk-Based Development Trunk-Based Development by Atlassian, edited / CC BY

Trunk-Based Development Workflow

  1. Work on the main codebase: Work directly on the main (trunk) branch, rather than creating separate branches.

  2. Make small, frequent changes: Make small and incremental changes to the codebase, which are easier to review and less likely to cause issues.

  3. Use Continuous Integration: Integrate and test the codebase frequently in order to detect issues early, avoid conflicts, and ensure that the codebase is always in a releasable state.

  4. Merge changes frequently: Merged changes frequently back into the main codebase, keeping it up-to-date and reducing the likelihood of conflicts.

Pros and Cons

Advantages Disadvantages
Encourages collaboration and
rapid feedback
Can lead to conflicts and
integration issues if not
managed properly
Promotes early issue detection
and quick resolution
Requires robust automated
testing and continuous
integration practices
Facilitates faster feature
and improvement delivery
Can be difficult to roll
back changes once
integrated into main
Simplifies codebase management
by keeping all developers
on the same branch
May not be suitable for
larger teams or complex
Reduces overhead of
feature branches
Single point of failure
if main becomes unstable

Teams and Projects

Trunk-based development is suitable for projects with small teams, short release cycles, and a focus on delivering new features and improvements quickly.

Strategy 2: Feature Branching

What is Feature Branching?

Feature Branching is a commonly used workflow that involves creating a new branch for a specific feature or change in the codebase. This allows developers to work on the feature independently without affecting the main branch. When the feature is complete, it can be merged back into the main branch through a pull request. The pull request allows other team members to review the changes and suggest modifications or improvements before merging the feature into the main branch.

Feature Branching Feature Branching by Atlassian, edited / CC BY

Feature Branching Workflow

  1. Create feature branches: Create a new branch for each feature or task you’re working on. This branch should be created from the main branch.
  2. Work on the feature: After creating the feature branch, you can start implementing the new feature by making as many commits as necessary. The branch should only contain changes relating to that particular feature.
  3. Create a pull request: When you’re finished working on the feature branch, you create a pull request to merge the changes into the main branch.
  4. Review and approve: Other developers review the changes in the pull request and approve them if they are satisfied with the changes. Code review can help catch issues or mistakes before they are merged into the main branch.
  5. Merge the feature branch: Once you’re done working on the feature, you can merge the feature branch back into the main branch.
  6. Clean up: After merging, you can delete the feature branch, as it is no longer needed.

Pros and Cons

Advantages Disadvantages
Allows parallel feature
Managing and updating
numerous branches
Facilitates controlled
code review/testing
Delays in merging changes
into main due to
extended review
Ensures consistent stability
of the main branch
Can lead to conflicts due
to branch dependencies
Enhances change tracking Extra effort to
synchronize branches with
changes in main

Teams and Projects

Feature Branching is commonly used in collaborative software development environments where multiple developers are working on different features or tasks concurrently.

Strategy 3: Git Flow

What is Git Flow?

Git Flow is a branching strategy that uses two main long-lived branches - main and develop - that remain in the project during its entire lifetime. Additionally, it employs several short-lived branches - feature, release, and hotfix - that are created as needed to manage the development process and deleted once they have fulfilled their purpose. The main branch is the stable production-ready code and the develop branch is where all development takes place. Feature branches are used to develop new features or changes, release branches are used to prepare for a new release, and hotfix branches are used to quickly address critical issues in the production code.

Git Flow Git Flow by Atlassian / CC BY

Git Flow Workflow

  1. Create the develop branch: This branch will be used for ongoing development work. A develop branch is created from the main branch.
  2. Create feature branches: When starting work on a new feature or bug fix, create a new feature branch from the develop branch.
  3. Develop and merge the feature branch into develop: Make any necessary changes to your local code on the feature branch. Once the feature is complete and tested, merge the branch back into the develop branch.
  4. Create the release branch: When it’s time to prepare a new release, create a new release branch from the develop branch with a descriptive name that includes the version number, for example, release/1.0. Test the release thoroughly to catch any bugs or issues to ensure it’s production-ready.
  5. Merge the release branch into main: Once the release is ready, merge the release branch into the main branch and tag it with a version number. Use a pull request to ensure code reviews and approval from other team members.
  6. Repeat the process: Once the release is complete, switch back to the develop branch and start the process over again with a new feature branch.

If a critical issue in the main branch is detected:

  • Create a hotfix branch from main: This branch is used to quickly fix critical issues or bugs in the production code that cannot wait for the next release cycle.
  • Merge the hotfix branch into both develop and main: After the hotfix is completed and tested, it is merged into both the develop and main branches to ensure that the fix is applied to both the ongoing development work and the production code.

Pros and Cons

Advantages Disadvantages
Provides clear structure
for managing code changes
Can be more complex
than other branching
Separates ongoing development
from stable releases
Potential for larger
number of branches
Encourages use of short-lived
feature, release, and
hotfix branches
Possibility of
merge conflicts
Facilitates code review
and testing processes
Requires a certain level
of discipline and adherence
to process
Predictable development
Can be seen as
overly prescriptive or

Teams and Projects

Git Flow is particularly well-suited for larger development teams that are working on complex software applications with long development cycles and multiple releases. Smaller teams or projects with shorter development cycles may find Git Flow to be overly complex.


Strategy Project Type Team Size Collaboration Maturity
For projects with
frequent code changes
and continuous releases
High collaboration and
communication needed,
as all changes are
made directly to main
Projects with
development of
different features
Medium or
Moderate collaboration
maturity, as changes
occur in separate
branches before
merging into main
Git Flow Projects requiring
a structured approach
High collaboration
maturity, as changes
involve multiple
branches and a
formalized release
  • Trunk-Based Development is a Git branching strategy that emphasizes frequent integration and testing on the main branch to ensure a high level of collaboration and continuous delivery.
  • Feature Branching is a Git branching strategy that involves creating separate branches for individual features or changes to allow for isolation, testing, and review before merging into the main branch.
  • Git Flow is a Git branching model that builds on Feature Branching by adding additional branches for managing releases and hotfixes, providing a structured approach for managing different types of changes in larger teams or more complex projects.
Contributed by Paulina Ambroziak