GITFlow definition for all projects on gitlab

1. GIT - gitflow
R&D

2. GITFLOW
2
❑ Requirements :
● We want a stable (main) branch that is indisputable without having to search for the
latest tag to avoid (human) error
● We want an integration/pre-production branch that will serve as an intermediate
branch to help stabilize developments without impacting the stable branch.
● We want a development branch which will by definition be the unstable branch (which
is completely normal) in which all the branches will be merged after a Merge request.
● Merge requests allow code review and thus participate in the cross-functional sharing of
development knowledge within the team.

3. 3
■ Thus, all git repo MUST have three default branches :
 main : the stable branch similar to the production
 integration : the branch used for intermediate integration is the equivalent of a
preproduction
 development : the unstable branch used to merge the developments to be integrated
GITFLOW

4. GITFLOW
4
❑ Thus, the official GITFLOW to be use is the following one :
main/stable/production
preprod/integration
Development/unstable
HOTFIX / ID-JIRA / DESCRIPTION
BUGFIX / ID-JIRA / DESCRIPTION
FEATURE / ID-JIRA / DESCRIPTION
TAG1 TAG2
rebase
rebase
rebase
Merge
request
Merge
request
Merge
request
Merge
request
MR
Merge
request
Push
+
merge
request
Push
+
merge
request
Push
+
merge
request

5. 5
GITFLOW
Main
(stable’s branch)
Integration’s branch
Develop
(unstable’s branch)
HOTFIX
branch
branch
branch
Push on
the bugfix
branch
BUGFIX
FEATURE
Rebase
branch
branch
Rebase
Push + Merge
Request
Push + Merge
Request
All branches merged into this
integration branch should reflect
what will be described in the final
release note.
RC
9.1.0
RC
9.1.1
HOTFIX
branch
Merge
Request
Merge
Request
Merge
Request
Merge
Request
9.0.0 9.1.1
Merge
Request
Push on
the bugfix
branch
Merge
Request
Merge
Request
CI : linters (gitlab)
Hotfix
release
Official
release
Hotfix
release
If the
hotfix is
clean!
If the
hotfix is
clean!
Jenkins nightly build +
sanity tests
Jenkins build +
focus test on
the hotfix
Jenkins build +
focus test on
the hotfix
Jenkins build + complete tests
Jenkins nightly build +
sanity tests

6. 6
GITFLOW
main
integration
develop
hotfix
bugfix
feature
Push
Merge
request
Create
branch
Create
branch
Create
branch
Create
branch
Create
branch
Rebase
Hotfix
release
Jenkins build +
focus test on
the hotfix
Jenkins nightly
build + sanity
tests
Push
Merge
request
Rebase
Jenkins nightly
build + sanity
tests
CI : linters (gitlab)
Merge
request
Merge
request
Jenkins build + complete tests
9.0.0 9.1.1
Official
release
Merge
request

7. GITFLOW
7
❑ 1. Direct push on the develop/maintenance/main branches are forbidden to guarantee the smooth running of the
workflow.
❑ 2. A push to origin (gitlab) on a well-named branch (using correct patterns) is allowed. The push in its feature branch
must be able to trigger the gitlab CI like the linters (cppcheck, sonarcube, pylint, dockerlint, .... ) and thus create a
verification at the source and send an email to the author and forbid him to go further until this step is safe.
❑ 3. A merge request (aka MR) must be done manually by the developer of his branch from the gitlab UI by specifying
one or more people for a code review. At least one person must approve the code for it to be validated and to be able
to validate the merge to the develop branch. Once merged, the branch can be destroyed automatically.
❑ 4. If it is not approved, it is possible to modify its code and go back to step 2 while keeping the MR open. If validated,
this step allows other developers to get the functionality.
❑ 5. When preparing a release, a new merge request (without code review) is made by the release builder. Merge
request and validation in stride should allow to have a precise visibility of what will be validated and also to be able to
have an idea of the final changelog.
❑ 6. Before launching a validation, a tag is placed because it will identify the Release candidate (aka RC) in the making.
Even if they can be launched on the develop branch, it is at this stage that the complete auto tests can be launched in
order to validate the version (in addition to the manual tests). This step is iterated until it is stable for a client
delivery.
❑ 7. Once stable and validated, a last MR is done manually because the content of the integration branch which
corresponds to the last validated RC becomes the new stable branch.

8. GITFLOW
8
❑ Some gitlab settings to affect to all git repos :
● Configure your repos to prohibit any direct git push without going through a branch and a merge request :
https://docs.gitlab.com/ee/user/project/protected_branches.html
● Branches must have a correct pattern :
▶ hotfix/ID-JIRA/description : must be created from the master/stable’s branch and forward to the preprod then develop ; it must be used to
fix a major and urgent bug in production
▶ bugfix/ID-JIRA/description : must be created from the develop’s branch then merge to preprod, finaly to master ; it must be used to fix a
minor bug
▶ feature/ID-JIRA/description : must be created from the develop’s branch then merge to preprod, finaly to master ; it must be used to
develop a new feature
▶ All branch name mus be in lower case !
● Those pattern can be forced in GITLAB using a regexp :
https://docs.gitlab.com/ee/user/project/repository/push_rules.html
The ID-JIRA is important if gitlab is linked with JIRA
● Link gitlab with jira in order to add traceability and synchronization of commits :
https://about.gitlab.com/blog/2021/04/12/gitlab-jira-integration-selfmanaged/

9. ❑ The modification of the git flow may give rise to a tiny modification
of:
o jenkins for the generation of releases.
o the git repo cache configuration from git(lab)
❑ Survey available on the drive :
https://docs.google.com/presentation/d/1nK76saocbz2mVaEurreW63q-
4WfHhFkF/edit?usp=share_link&ouid=113587050683981420435&rtpof=
true&sd=true
GITFLOW
9

10. ENENSYS
4A rue des Buttes
CS 37734
35 577 Cesson-Sévigné – France
Phone (+33) 1 70 72 51 70
Email contact@test-tree.com
www.enensys.com
10