How to Understand GitFlow - Documentation, Training, Environments and Workflows

Table of content:

GitFlow - Documentation & Training Resources

• GitFlow Diagram
• GitFlow Documentation
• Semantic Versioning Documentation:
• GitFlow Training Meeting Recording

GitFlow - Environments and Branches

• Types of Branches
• Environments - Mapping Git Branches to Server Environments

GitFlow - Step by Step Branch Workflows

• Feature - Creating new Features as part of the sprint
• Bugfix on Develop Branch - Working on Bug Fixes as part of the sprint
• Bugfix on Release Branch - Working on Bug Fixes during Staging and QA, prepping for a release Hotfix - Priority bugfix on production
• Release - Preparing a group of features and BugFfixes to deploy to production

Additional Notes

GitFlow - Documentation & Training Resources

GitFlow Diagram

GitFlow Documentation

Git Workflow

Semantic Versioning Documentation:

Semantic Versioning 2.0.0

GitFlow Training Meeting Recording

AptivePay Devs - GitFlow Training (2021-11-16 at 08_03 GMT-8).mp4

GitFlow - Environments and Branches

Types of Branches

Environments - Mapping Git Branches to Server Environments

There are 4 different environments in GitFlow:

Local Development Environment

The local development environment exists on individual developer machines. This is where the coding work for features, bug fixes, and hotfixes are performed. Feature, bugfix, and hotfix branches exist here prior to the merge.

Testing

This is where features are integrated together and where QA does the initial testing of features and bugs that have been completed and merged in by the Code Review. The development  branch should be deployed to this environment when changes are merged.

Staging

This should be as close to production as possible. This is where User Acceptance Testing is performed. The release  branch should be deployed to this environment when changes are merged.

Production

This should be where the production code utilized by end users runs. The master branch should be deployed to this environment when changes are merged.

GitFlow - Step by Step Branch Workflows  

Feature - How to Create new Features as part of the sprint

• Pull develop branch (Get all changes on your local machine)
• Create feature branch from develop branch - feature/<task-id>/<title>
• Work on the code for the feature on the feature branch
• Pull develop branch (Get all changes on your local machine)
• Merge develop branch into feature branch (Get all changes for the develop branch into the feature branch)
• Resolve merge conflicts
• Ensure all unit tests are passing
• Submit a Pull/Merge Request for the feature branch into the develop branch (Code Review)
• Make any changes requested by the reviewer on the feature branch
• Ensure all unit tests are passing
• Reviewer approves and merges the feature branch into develop branch

How to Bug fix on Develop Branch - Working on Bug Fixes as part of the sprint

• Pull develop branch (Get all changes on your local machine)
• Create bugfix branch from develop branch - bugfix/<task-id>/<title>
• Work on the code for the bugfix on the bugfix branch
• Pull develop branch (Get all changes on your local machine)
• Merge develop branch into bugfix branch (Get all changes for the develop branch into the bugfix branch)
• Resolve merge conflicts
• Ensure all unit tests are passing
• Submit a Pull/Merge Request for the bugfix branch into the develop branch (Code Review)
• Make any changes requested by the reviewer on the bugfix branch
• Ensure all unit tests are passing
• Reviewer approves and merges the bugfix branch into develop branch

How to Bugfix on Release Branch - Working on Bug Fixes during Staging and QA, prepping for a release

• Pull release branch (Get all changes on your local machine)
• Create bugfix branch from release branch - bugfix/<task-id>/<title>
• Work on the code for the bugfix on the bugfix branch
• Pull release branch (Get all changes on your local machine)
• Merge release branch into bugfix branch (Get all changes for the release branch into the bugfix branch)
• Resolve merge conflicts
• Ensure all unit tests are passing
• Submit a Pull/Merge Request for the bugfix branch into the release branch (Code Review)
• Make any changes requested by the reviewer on the bugfix branch
• Ensure all unit tests are passing
• Reviewer approves and merges the bugfix branch into release branch

Hotfix - How to Priority bugfix on production

• Pull master branch (Get all changes on your local machine)
• Create hotfix branch from master branch - hotfix/<major.minor.patch+1>
• Work on the code for the hotfix on the hotfix branch
• Pull master branch (Get all changes on your local machine)
• Merge master branch into hotfix branch (Get all changes for the master branch into the hotfix branch)
• Resolve merge conflicts
• Ensure all unit tests are passing
• Submit a Pull/Merge Request for the hotfix branch into the master branch (Code Review)
• Make any changes requested by the reviewer on the hotfix branch
• Ensure all unit tests are passing
• Reviewer approves and merges the hotfix branch into master branch
• Merge hotfix branch into develop branch (Get hotfix changes into develop branch)
• Merge hotfix branch into release branch (Only if there is a current release branch being worked on)

Release - How to Prepare a group of features and bug fixes to deploy to production

• Pull develop branch (Get all changes on your local machine)
• Create release branch from develop branch - release/<major.minor.patch>
• Deploy release branch to QA environment (Pre release QA testing)
• Deploy release branch to Staging environment (User Acceptance Testing)
• QA release branch (Also Ensure all types of tests are passing)
• Fix any QA issues using the "Bugfix on Release Branch" workflow
• Merge release branch to master branch (Deploy to production)
• Tag the master branch with the release version number
• Merge the release branch to the develop branch (Get all changes on release branch into develop branch)

Additional Notes

When possible, strive to only work on features for one major or minor version at a time.

Example:

Don’t try to work on features for v1.3.0 at the same time as v1.4.0. This potentially complicates things as you CANNOT merge the v1.4.0 feature back into develop until you have created the release/1.3.0 branch

If you have to work on the v1.4.0 feature at the same time as the v1.3.0 feature then DO NOT merge the v1.4.0 feature back into develop until you have created the release/1.3.0 branch. This means that you cannot pass the “Code  Review” phase for the v1.4.0 feature until AFTER the release/1.3.0 branch is created.

For free consultation on GitFlow documentation, training, environments, and workflows, click here.