Scribd
Upload
15 views3 pages

Git Flow Strategies

Uploaded by

Ionut Mocoi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
15 views3 pages

Git Flow Strategies

Uploaded by

Ionut Mocoi
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Git Flow Strategies

A branching strategy is the strategy the software development team adopts when writing, merging and deploying code using a
version control system. ( eg. Bitbucket, Github )

The git flow strategy is implemented in the Continous Integration and Continous Delivery (CI/CD) flow from the application repositories.

The commit messages must follow Conventional Commits specification. Conventional commits is a specification for adding human and
machine-readable meaning to commit messages.

What is a git branch?

Branches are a part of everyday development. A git branch is a movable pointer to a commit, allowing us to have a snapshot of our
changes. When we want to add new functionalities or fix bugs, we create new branches to encapsulate our changes before being
merged into stable environments.

Naming convention:

1 [branch-type]/[issue-identifier]-[issue-title]

feature/CSS-2-integrate-dependabot

The issue identifier usually represents the task ID from Jira or other task management tools.

Branch types

Supporting Branches

They are used in git flows to work on new functionalities, fix bugs, and improve code structure and settings.

feature/[issue-id]-[issue-title]
The feature branches are used to work on a new feature for one of the upcoming releases.
chore/[issue-id]-[issue-title]
The chore branches are used for working on tasks that do not add a new feature to the codebase. They are used for tasks that update the
code structure, configurations, pipelines, or other non-functionality-related tasks.

bugfix/[issue-id]-[issue-title]
The bugfix branches are used to work on fixing a bug that appeared on the project. These branches are used to fix bugs that are allowed
to enter one of the upcoming releases and they do not need to be merged directly into the production branch after finishing the fix. If the fix
needs to be entered ASAP in the production branch without waiting for the next release, a hotfix branch must be used.
hotfix/[issue-id]-[issue-title]
The hotfix branches are used for working on bug fixes that need to reach the production environment before the next release happens.
They are created when there is a critical bug that blocks important functionalities for the application. As soon as the bug is fixed, the branch
reaches the production branch without waiting for the next release.
Main Branches

They are used to reflect different application environments and the code that reaches these branches needs to be stable. Depending on the
flow, there are multiple points where the added functionalities are tested to ensure the stability of the code.

Git Flow

Main Branches: DEVELOPMENT RELEASE/X.Y.Z STAGING MASTER

DEVELOPMENT

The development branch is used as the main branch. The branch is kept up to date with the active release branch and represents the
place from where we create new RELEASE/X.Y.Z branches.

Merge strategy: Fast Forward from the active release branch

Reflected environment: No environment

Pull Request source: No PRs are required from the main branches.

RELEASE/X.Y.Z

The release branches are used for keeping all the code for the upcoming release. The release with the lowest version is considered the
active release, the others are considered inactive release branches. Once merged the branch is deleted.

Merge strategy: Fast Forward

1 git checkout release/x.y.z


2 git merge --squash chore/LIN-01-create-git-flow
3 git commit -m "chore: Create git flow"
4 git push origin release/x.y.z

Reflected environment: Testing

Pull Request source: Supporting branches

STAGING

The branch is used as the environment where the next release is tested before reaching a production-ready state and where regression
testing is done to ensure the stability of the system.

This branch is usually skipped in smaller projects where we do not have to do a regression. In those cases, we push the code
from the release branches directly into the master branch.

Merge strategy: Fast Forward

1 git checkout master


2 git merge release/x.y.z --ff-only

Reflected environment: Staging

Pull Request source: Active Release Branch

MASTER
The master branch reflects the production environment. When a release is stable and goes through all the testing steps, it is merged into
the master branch. When the code reaches the master branch, a new release tag is created with the active release version.

After the active release code is available on this branch, the active release branch needs to be deleted. In this way, the next
release branch will be automatically considered the active release

Merge strategy: Fast Forward

1 git checkout master


2 git merge staging --ff-only

Reflected environment: Production

Pull Request source: Staging

You might also like