Git-flow

Branches
Git Flow is a popular workflow designed around the project release that assigns very specific
roles to different branches and defines how and when they should interact.

A typical Git Repository will have 03 main branches:

 master branch holds source code latest for production

 develop branch holds source code for “next releases” development

 staging branch holds source code for “demo”. When PO confirm for release

.* Note: Only Pull requests are allowed to merge into production and develop branches with the
following merging strategy:

Convention for branch names

 Feature branches: feature/<ticket-id>[-<ticket-name>] for example feature/SMSC-123-
report-screen.

 Bugfix branches: bugfix/<ticket-id>[-<ticket-name>] for example bugfix/SMSC-123-

report-incorrect.

 Hotfix branches: hotfix/<ticket-id>[-<ticket-name>] for example hotfix/SMSC-500-

loading-icon.

 Versioning: with convention <major>.<minor>.<patch>-RELEASE

o Release branches: release/<version> for example release/1.0.0-RELEASE

Commit convention
Commit message is REQUIRED to explain what team members worked on that commit.

Process
Following steps demonstrate the git process of a team for example (naming & roles in the
example are for purpose of referencing only, and can be changed for a better suit with an actual
project development team):

Feature:
1. Developer creates feature branch (from develop branch) base on ticket assigned for
example:

o git checkout –b feature/[ticket id]-[short description] develop

o git push --set-upstream origin feature/[ticket id]-[short description]

2. Once the developer finishes working on the feature, the developer creates a merge
request from the feature branch (feature/[ticket id]-[short description]) to develop the
branch and assigns it to reviewers for reviewing after the developer makes sure the
following things:

1. Feature branch included the latest changes in develop branch without any
conflict

2. Feature branch meets all the requirements of the relevant ticket

3. Feature branch meets the sonar scan

4. Feature branch meets the unit test coverage that the team agreed during current
Sprint planning
 5. Feature branch meets the coding standard

. If review defects are found during the review, the developer works on the feature branch
until all review defects are fixed and notify reviewers for review again.

. Reviewers accept merge request and only Maintainers (belong Maintainer group) are able
to merge Pull Request to develop branch

. Defects found during testing are tracked into Jira in separated ticket and has to be linked
to the Feature ticket and will be following bugfix branch

Bugfix:

1. Developer creates bugfix branch from develop branch to work on defect fixing.

2. Once bugfix is done, the developer follows steps 2, 3 & 4 defined in the Feature session
to create merge request, fix review defects (if any) then deploy lasted develop branch
then QC is able to verify again.

Hotfix:
Continuous Delivery:
1. Project Team Leader works with Product Owner to determine the release plan for product
development

2. Technical Lead creates release branch from develop branch to prepare for release.

3. release branch will be flexible deployed in QA or Staging environment

4. After passed Staging testing, the release branch will be merged to master branch to
deploy in the production environment

5. All the bugfix or hotfix for the release phase will be a clone and create the new branch
base on the release branch. Code will be merging and test on Staging and Production
then need to merge the code from the release branch to develop branch to keep the latest
updated.