Select Page

A git workflow that is easy and scale for product development

A git workflow that is easy and scale for product development

There are numerous GIT workflow floating around like Centralized Workflow, Gitflow, Forking flow and Feature Branch Workflow

Over the last 10 years, I have followed this really simple workflow, similar to the forking flow.
  • it allow Parallel Development, features branches can be merged to any release branches or ideally Master
  • Collaboration Feature branches also make it easier for two or more developers to collaborate on the same feature

We consider Master the stable version of the product, this branch should be deployed automatically using continuous delivery

Every ticket, bugs, fix, features

is done first in a new branch from master

  • Using the ticket number first,
  • with a short but understandable description written in lower case, e.g. PROJ-11-fix-login. This will let you create automatic releases notes because Jira and Confluence will recognize the ticket number in the branch name

These ticket, bugs, fix, features should NEVER be merged to master without a Pull Request (PR) and a code review.

After the review process it can be merged to master. (merge will be blocked if no reviewer has accepted the code changes)

Delivering code

Code deployed to production or customer instance can ONLY be deployed from a release branch name 1.0, 1.1, 1.2,….

Fixes in production or customer release

Fixes in production or customer release branch are done the usual way (ticket-name but branch created from release branch name) and create a new git tag 1.0.1 (first fix of release 1.0.1, then 1.0.2 ….)

These branches created from release branches can but must NOT be merged to master depending on the quality of the fix and urgency. To be discussed on a case by case basis

  • e.g. hot ugly fixes, aka workaround, done in urgency for a customer wont be merged to master and may be rewritten to finally be merged to master later.
  • But the normal case it that these fixes will be merged to master.


This workflow has allowed me in the past to handle multiple version (1.1, 1.2.5, 1.5) of a corporate product run by multiple client at the same time. Even if supporting multiple version is not a desirable setup in the long run…

0 0 votes
Article Rating
Notify of
Inline Feedbacks
View all comments


Would love your thoughts, please comment.x