# Gitflow branching strategy Gitflow is a branching model that involves the use of multiple branches to move code from development to production. Gitflow works well for teams that have scheduled release cycles and a need to define a collection of features as a release. Development is completed in individual feature branches that are merged, with approval, into a develop branch, which is used for integration. The features in this branch are considered ready for production. When all planned features have accumulated in the develop branch, a release branch is created for deployments to upper environments. This separation improves control over which changes are moving to which named environment on a defined schedule. If necessary, you can accelerate this process into a faster deployment model. For more information about the Gitflow branching strategy, see the following resources: + [Implement a Gitflow branching strategy for multi-account DevOps environments](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (AWS Prescriptive Guidance) + [The original Gitflow blog](https://nvie.com/posts/a-successful-git-branching-model/) (Vincent Driessen blog post) + [Gitflow workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian) **Topics** + [ # Visual overview of the Gitflow strategy ](visual-overview-of-the-gitflow-strategy.md) + [ # Branches in a Gitflow strategy ](branches-in-a-gitflow-strategy.md) + [ # Advantages and disadvantages of the Gitflow strategy ](advantages-and-disadvantages-of-the-gitflow-strategy.md) # Visual overview of the Gitflow strategy The following diagram can be used like a [Punnett square](https://en.wikipedia.org/wiki/Punnett_square) to understand the Gitflow branching strategy. Line up the branches on the vertical axis with the AWS environments on the horizontal axis to determine what actions to perform in each scenario. The circled numbers guide you through the sequence of actions represented in the diagram. For more information about the activities that occur in each environment, see [DevOps environments](understanding-the-devops-environments.md) in this guide. ![\[Punnett square of the Gitflow activities in each branch and environment\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png) # Branches in a Gitflow strategy A Gitflow branching strategy commonly has the following branches. ![\[The branches and environments in a Gitflow branching strategy.\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png) ## feature branch `Feature` branches are short-term branches where you develop features. The `feature` branch is created by branching off of the `develop` branch. Developers iterate, commit, and test code in the `feature` branch. When the feature is complete, the developer promotes the feature. There are only two paths forward from a feature branch: + Merge into the `sandbox` branch + Create a merge request into the `develop` branch | | | | --- |--- | | Naming convention: | `feature/__` | | Naming convention example: | `feature/123456_MS_Implement_Feature_A` | ## sandbox branch The `sandbox` branch is a non-standard, short-term branch for Gitflow. However, it is useful for CI/CD pipeline development. The `sandbox` branch is primarily used for the following purposes: + Perform a full deployment to the sandbox environment by using the CI/CD pipelines rather than a manual deployment. + Develop and test a pipeline before submitting merge requests for full testing in a lower environment, such as development or testing. `Sandbox` branches are temporary in nature and are not meant to be long-lived. They should be deleted after the specific testing is complete. | | | | --- |--- | | Naming convention: | `sandbox/__` | | Naming convention example: | `sandbox/123456_MS_Test_Pipeline_Deploy` | ## develop branch The `develop` branch is a long-lived branch where features are integrated, built, validated, and deployed to the development environment. All `feature` branches are merged into the `develop` branch. Merges into the `develop` branch are completed through a merge request that requires a successful build and two developer approvals. To prevent deletion, enable branch protection on the `develop` branch. | | | | --- |--- | | Naming convention: | `develop` | ## release branch In Gitflow, `release` branches are short-term branches. These branches are special because you can deploy them to multiple environments, embracing the build-once, deploy-many methodology. `Release` branches can target the testing, staging, or production environments. After a development team has decided to promote features into higher environments, they create a new `release` branch and use increment the version number from the previous release. At gates in each environment, deployments require manual approvals to proceed. `Release` branches should require a merge request to be changed. After the `release` branch has deployed to production, it should be merged back into the `develop` and `main` branches to make sure that any bugfixes or hotfixes are merged back into future development efforts. | | | | --- |--- | | Naming convention: | `release/v{major}.{minor}` | | Naming convention example: | `release/v1.0` | ## main branch The `main` branch is a long-lived branch that always represents the code that is running in production. Code is merged into the `main` branch automatically from a release branch after a successful deployment from the release pipeline. To prevent deletion, enable branch protection on the `main` branch. | | | | --- |--- | | Naming convention: | `main` | ## bugfix branch The `bugfix` branch is a short-term branch that is used to fix issues in release branches that haven't been released to production. A `bugfix` branch should only be used to promote fixes in `release` branches to the testing, staging, or production environments. A `bugfix` branch is always branched off of a `release` branch. After the bugfix is tested, it can be promoted to the `release` branch through a merge request. Then you can push the `release` branch forward by following the standard release process. | | | | --- |--- | | Naming convention: | `bugfix/__` | | Naming convention example: | `bugfix/123456_MS_Fix_Problem_A` | ## hotfix branch The `hotfix` branch is a short-term branch that is used to fix issues in production. It only be used to promote fixes that must be expedited to reach the production environment. A `hotfix` branch is always branched from `main`. After the hotfix is tested, you can promote it to production through a merge request into the `release` branch that was created from `main`. For testing, you can then push the `release` branch forward by following the standard release process. | | | | --- |--- | | Naming convention: | `hotfix/__` | | Naming convention example: | `hotfix/123456_MS_Fix_Problem_A` | # Advantages and disadvantages of the Gitflow strategy The Gitflow branching strategy is well suited to larger, more distributed teams that have strict release and compliance requirements. Gitflow contributes to a predictable release cycle for the organization, and this is often preferred by larger organizations. Gitflow is also well suited for teams that require guardrails to complete their software development lifecycle properly. This is because there are multiple opportunities for reviews and quality assurance built into the strategy. Gitflow is also well suited for teams that must maintain multiple versions of production releases simultaneously. Some disadvantages of GItflow are that is it more complex than other branching models and requires strict adherence to the pattern to complete successfully. Gitflow does not work well for organizations striving for continuous delivery due to the rigid nature of managing release branches. Gitflow release branches can be long-lived branches that can accumulate technical debt if not properly addressed in a timely manner. ## Advantages Gitflow-based development offers several advantages that can improve the development process, streamline collaboration, and enhance the overall quality of the software. The following are some of the key benefits: + **Predictable release process** – Gitflow follows a regular and predictable release process. It is well suited to teams with regular development and release cadences. + **Improved collaboration** – Gitflow encourages the use of `feature` and `release` branches. These two branches help teams work in parallel with minimal dependencies on each other. + **Well suited for multiple environments** – Gitflow uses `release` branches, which can be longer-lived branches. These branches enable teams to target individual releases over a longer period of time. + **Multiple versions in production** – If your team supports multiple versions of the software in production, Gitflow `release` branches support this requirement. + **Built-in code quality reviews** – Gitflow requires and encourages the use of code reviews and approvals before code is promoted to another environment. This process removes friction between developers by requiring this step for all code promotions. + **Organization benefits** – Gitflow has advantages at an organization level as well. Gitflow encourages the use of a standard release cycle, which helps the organization understand and anticipate the release schedule. Because the business now understands when new features can be delivered, there is reduced friction about timelines because there are set delivery dates. ## Disadvantages Gitflow-based development does have some disadvantages that can impact the development process and the team dynamics. The following are a few notable drawbacks: + **Complexity** – Gitflow is a complex pattern for new teams to learn, and you must adhere to the rules of Gitflow to use this successfully. + **Continuous deployment** – Gitflow doesn't fit a model where many deployments are released to production in a rapid fashion. This is because Gitflow requires the use of multiple branches and a strict workflow governing the `release` branch. + **Branch management** – Gitflow uses many branches, which can become burdensome to maintain. It can be challenging to track the various branches and merge released code in order to keep the branches properly aligned with each other. + **Technical debt** – Because Gitflow releases are typically slower than the other branching models, more features can accumulate for release, which can cause technical debt to accumulate. Teams should carefully consider these drawbacks when deciding whether Gitflow-based development is the right approach for their project.