Introduction

For a long time, I thought there was only one way to use Git: having a master branch, a develop branch, story/feature branches, hotfix branches, and release branches. This model is often referred to as Gitflow. However, once I started working and got introduced to trunk-based development, I found it interesting and wanted to write a post about it.

Git Flow

Before diving into trunk-based development, I want to first introduce Gitflow and review some important concepts under this model. The primary components of Gitflow are:

• **master**branch (aka main branch): This branch keeps track of the release history. In other words, code is only merged into this branch when it is ready to be deployed to production.
• develop branch: This branch contains new changes being made and is often used for testing in a non-production environment. It ensures that new changes work as expected alongside other people’s changes (assuming multiple developers are working on the same branch).
• Release branches: These branches contain only the features scheduled for release in a given cycle. Often, we perform an operation known as cherry-picking to select features that have been fully tested in develop. Release-related tasks, such as documentation work, can also be added here.
• Story branches (aka feature branches): These branches are created off of develop to contain new changes before they are fully tested.
• Hotfix branches: Sometimes, we need to patch production quickly. In such cases, we create a hotfix branch directly off master. After finishing the patch, the hotfix branch is merged back into master. In other words, it functions similarly to a release branch but originates from master instead of develop.

General Workflow in Gitflow

1. As a developer working on a new feature, I branch off from the most up-to-date develop to create my story branch. After making changes and testing them on my story branch, I open a pull request (PR) to merge it into develop.
2. Once the PR is approved, I can deploy develop into a non-production environment for acceptance testing, ensuring that no features are broken and that the new feature functions as expected.
3. After discussing with the team, we decide to include my new feature in the upcoming release cycle along with other new features.
4. A release branch is created from develop, using the cherry-pick strategy to select my feature along with others being released in this cycle.
5. We have automated documentation generation tasks set up in our pipeline, which add documentation for the new features in the release branch.
6. Once all release-related tasks are completed, we merge the release branch into master and tag it with a version number.
7. We then merge the release branch back into develop to ensure the new documentation is included there as well.
8. At 3 AM, the on-call engineer is alerted to a major issue with the new release. A meeting is started, and with my coffee ready, we branch off master to create a hotfix branch. After two hours of battling, we fix the bug, merge the hotfix branch back into master, and deployed to production.
9. Finally, we merge the hotfix branch into develop to ensure the fix is included in ongoing development.