Table of Contents
Overview
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 building block, we’ll go over three popular Git branching strategies:
- Trunk-Based Development
- Feature Branching
- 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 Workflow
- Work on the
maincodebase: Work directly on themain(trunk) branch, rather than creating separate branches.
- Make small, frequent changes: Make small and incremental changes to the codebase, which are easier to review and less likely to cause issues.
- 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.
- Merge changes frequently: Merged changes frequently back into the
maincodebase, keeping it up-to-date and reducing the likelihood of conflicts.
Pros and Cons
Advantages | Disadvantages |
Encourages collaboration andrapid feedback | Can lead to conflicts andintegration issues if notmanaged properly |
Promotes early issue detectionand quick resolution | Requires robust automatedtesting and continuousintegration practices |
Facilitates faster featureand improvement delivery | Can be difficult to rollback changes onceintegrated into main |
Simplifies codebase managementby keeping all developerson the same branch | May not be suitable forlarger teams or complexprojects |
Reduces overhead ofmultiple feature branches | Single point of failureif 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 Workflow
- Create
featurebranches: Create a new branch for each feature or task you’re working on. This branch should be created from themainbranch.
- Work on the feature: After creating the
featurebranch, 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.
- Create a pull request: When you’re finished working on the
featurebranch, you create a pull request to merge the changes into themainbranch.
- 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
mainbranch.
- Merge the
featurebranch: Once you’re done working on the feature, you can merge thefeaturebranch back into themainbranch.
- Clean up: After merging, you can delete the
featurebranch, as it is no longer needed.
Pros and Cons
Advantages | Disadvantages |
Allows parallel featuredevelopment | Managing and updatingnumerous branches |
Facilitates controlledcode review/testing | Delays in merging changesinto main due toextended review |
Ensures consistent stabilityof the main branch | Can lead to conflicts dueto branch dependencies |
Enhances change tracking | Extra effort tosynchronize branches withchanges 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 Workflow
- Create the
developbranch: This branch will be used for ongoing development work. Adevelopbranch is created from themainbranch.
- Create
featurebranches: When starting work on a new feature or bug fix, create a newfeaturebranch from thedevelopbranch.
- Develop and merge the
featurebranch intodevelop: Make any necessary changes to your local code on thefeaturebranch. Once the feature is complete and tested, merge the branch back into thedevelopbranch.
- Create the
releasebranch: When it’s time to prepare a new release, create a newreleasebranch from thedevelopbranch 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.
- Merge the
releasebranch intomain: Once the release is ready, merge thereleasebranch into themainbranch and tag it with a version number. Use a pull request to ensure code reviews and approval from other team members.
- Repeat the process: Once the release is complete, switch back to the
developbranch and start the process over again with a newfeaturebranch.
If a critical issue in the
main branch is detected:- Create a
hotfixbranch frommain: 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
hotfixbranch into bothdevelopandmain: After the hotfix is completed and tested, it is merged into both thedevelopandmainbranches to ensure that the fix is applied to both the ongoing development work and the production code.
Pros and Cons
Advantages | Disadvantages |
Provides clear structurefor managing code changes | Can be more complexthan other branchingstrategies |
Separates ongoing developmentfrom stable releases | Potential for largernumber of branches |
Encourages use of short-lived feature, release, andhotfix branches | Possibility ofmerge conflicts |
Facilitates code reviewand testing processes | Requires a certain levelof discipline and adherenceto process |
Predictable developmentflow | Can be seen asoverly prescriptive orinflexible |
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.
Summary
Strategy | Project Type | Team Size | Collaboration Maturity |
Trunk-BasedDevelopment | For projects withfrequent code changesand continuous releases | Smallerteams | High collaboration andcommunication needed,as all changes aremade directly to main |
FeatureBranching | Projects withsimultaneousdevelopment ofdifferent features | Medium orlarge-sizedteams | Moderate collaborationmaturity, as changesoccur in separatebranches beforemerging into main |
Git Flow | Projects requiringa structured approach | Largerteams | High collaborationmaturity, as changesinvolve multiplebranches and aformalized releaseprocess |
Summary
- Trunk-Based Development is a Git branching strategy that emphasizes frequent integration and testing on the
mainbranch 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
mainbranch.
- 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.