Modeling the Code Lifecycle with Git Branches: A proposal

A clear Git branching strategy is essential for organizing software development, enabling collaboration and delivering value efficiently. There are various workflow models, each with its own strengths. Understanding the principles behind these workflows is key to tailoring the best strategy for a specific project or team.

In this article, we’ll explore a branch-based workflow example that illustrates common concepts in code management from development to deployment. While this diagram shows a specific approach, the underlying principles — such as using branches to isolate work, distinguishing between development and production-ready code, and managing versions — form the foundation of other popular methodologies like Gitflow, GitHub Flow, and Trunk-Based Development.

The diagram below serves as a visual guide to this example workflow:

Development and Integration

The core of our development cycle lies in creating new features and improvements. To manage this work in an organized and safe manner, we use short-lived branches for each individual task (Feature, Chore, Bugfix).

As illustrated in the previous diagram, each new piece of work is developed in a branch that stems from Main. Once completed and reviewed, the code is merged back into Main. This branch serves as the central integration point, collecting all stable and approved work. The tags we see on Main mark the exact points in history that correspond to released versions, consolidating all prior development and stabilization efforts into this main line.

Release Process

Preparing a new stable release for deployment is a distinct phase in our workflow.

To initiate a release, we create a release branch (e.g., release/1.1.0) from Main. The creation of this branch marks the beginning of a phase often accompanied by a Code Freeze—an optional practice in other contexts—where merging new features into Main is paused.
During this stabilization period, the focus shifts to the release branch. Thorough testing is conducted, and any bugs found are fixed directly in this branch. Once stable, the release branch is tagged with the final version (e.g., v1.1.0) and merged back into Main to incorporate all fixes into the mainline.

Hotfixes

When a critical bug arises in the version currently in production, we need a fast way to fix it. For this, we use hotfix branches.

For a hotfix, we create a branch directly from the tag on Main that corresponds to the version with the issue (e.g., from tag v1.2.0, we create hotfix/1.2.1). The fix is made in this hotfix branch. Once ready, it is merged back into Main to deploy the solution. The merge commit in Main is then tagged with the new version (e.g., tag v1.2.1).
It’s also crucial to merge the hotfix into any active development or release branches to prevent the bug from reappearing in future versions.

Conclusion

In conclusion, a structured Git workflow, like the example shown, is vital for predictable and reliable software development. Integration in Main is base for versions; the Release branch stabilizes before deployment; hotfixes quickly fix production issues. Models like this one, Gitflow, GitHub Flow, or TBD (Trunk-Based Development) are examples; adapting a clear Git flow to your needs is crucial for confident deliveries.