# Git Branching Strategy ## Trunk-Based Development (TBD) ### Characteristics - All developers work on a shared code base. - Developers commit all changes directly to a **single branch** in the version control system, known as the "trunk" or "**main**" branch. - Short-lived **feature** branches may be used but are merged back into the **main** frequently—usually at least once a day. - Relies heavily on continuous integration and automated tests to maintain code quality. - Features that are not ready for production are hidden behind **feature flags** or **toggles** until they are complete. - Database (or equivalent) table shapes (or equivalent) should be designed to be forwards/backwards compatible as far as possible. - Sometimes used together with **release** branches if planning releases periodically - > If a team is pushing **production releases monthly**, then they are also going to have to push bug-fix releases between planned releases. To facilitate that, it is common for Trunk-Based Development Teams to make a **release** branch on a just in time basis - say a few days before the release. That becomes a stable place, given the developers are still streaming their commits into the trunk at full speed. [^1] ![[Pasted image 20240326170512.png|Trunk, two and a half release branches, five releases (two planned, three unplanned), and two cherry-pick bug fixes]] > [!info] Trunk-Based Development without **feature** branches > > Imagine a situation requiring an immediate fix, where the development and testing environments are not prepared for production deployment: > > The production environment operates on an outdated version that urgently requires a crucial update. To address this, we initiate a **hotfix** branch named `hotfix/issue-123` originating from the production environment's current commit for rapid deployment. After testing in the staging environment, we can deploy to production. ### Advantages - Simplifies the development process by reducing the complexity of merging and managing multiple branches. - Encourages frequent integration and testing of changes, leading to early detection of conflicts and issues. - Facilitates continuous delivery and deployment practices by keeping the codebase in a release-ready state. ### Challenges - Requires a robust testing framework and automation to ensure that changes do not break the build. - Teams need to be disciplined in their commit practices to avoid introducing unstable code into the trunk. ## Feature Branch Workflow ### Characteristics - Development work on new features, bug fixes, or experiments is done in separate branches off the **main** branch, known as **feature** branches. - **Feature** branches are kept alive for the duration of the development work and are merged back into the **main** branch upon completion (both programmed and tested in isolation). - Code reviews and tests are conducted before merging a feature branch to ensure quality. ### Advantages - Allows developers to work on features independently without affecting the stability of the main codebase. - Facilitates parallel development of features by different team members or teams. - Enhances code quality through isolated testing and review processes (isolated environments for each feature). ### Challenges - Merging feature branches back into the main branch can result in merge conflicts, especially if the branches have diverged significantly over time. - Can lead to integration delays, where features developed in isolation might have compatibility issues when merged. ## GitFlow ### Characteristics - A branching model that defines a strict branching structure designed around project releases. - Utilizes multiple branch types, including **feature branches**, **release branches**, **hotfix branches**, and a **develop branch**. - **Feature** branches are used for new development, **release** branches prepare for a new production release, and all development work is merged into a **develop** branch before being merged into the main branch. - **Hotfix** branches are a lot like release branches and feature branches except they're based on main instead of develop. This is the only branch that should fork directly off of main. As soon as the fix is complete, it should be merged into both main and develop (or the current release branch), and main should be tagged with an updated version number. ### Advantages - Provides a clear structure and guidelines for managing releases, making it suitable for projects with scheduled releases. - Separates development work from release preparation, allowing for parallel development and release readiness activities. - Facilitates hotfixes to production issues without disrupting ongoing development. ### Challenges - The complexity of managing multiple branches can be cumbersome for small teams or projects. - The process can be slower than other methods, as it involves multiple stages of merging and testing before changes are released to production. ## References - https://trunkbaseddevelopment.com/ - https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow - https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow [^1]: https://trunkbaseddevelopment.com/branch-for-release/