Git Flow 
Branches 
Used branches are :
- main branch- pattern- main
- develop branch- pattern- develop
- feature branches- pattern- feat/wrong-header-title
- hotfix branches- pattern- hotfix/wrong-header-title
Feature branches should be merged into the develop branch, and the develop branch should be merged into the main branch (i.e. feature > develop > main).
Hotfix branches should be merged directly into the main branch (i.e hotfix > main), and the develop branch should then be rebased on the main branch.
The git tree should looks something like this :
*   ef33162 Merge branch 'release/v1.3.1' into main
| \
|  * 1c4c85f (release/v1.3.1) chore(bot): release v1.3.1
| /
*   1a2b3c4 Merge branch 'hotfix/security-headers' into main
| \
|  * 5d6e7f8 (hotfix/security-headers) fix(api): add security headers
| /
*   e92b3d2 Merge branch 'release/v1.3.0' into main
| \
|  * 3b6e7a8 (release/v1.3.0) chore(bot): release v1.3.0
| /
*   9a8c7c8 Merge branch 'develop' into main
| \
|  *   939c4c4 Merge branch 'pre-release/v1.3.0' into develop
|  | \
|  |  * 2ac6d3d (pre-release/v1.3.0) chore(bot): pre-release v1.3.0
|  | /
|  *   8b7c6d5 Merge branch 'feat/add-sso' into develop
|  | \
|  |  * 2a3b4c5 (feat/add-sso) feat(ui): use sso authentification
|  | /
|  *   895b0b6 Merge branch 'pre-release/v1.2.4' into develop
|  | \
|  |  * 854823b (pre-release/v1.2.4) chore(bot): pre-release v1.2.4
|  | /
|  *   9a8b7c6 Merge branch 'fix/navbar-responsive' into develop
|  | \
|  |  * 3e4f5g6 (fix/navbar-responsive) fix(ui): handle responsive on navbar
|  | /
| /
* 7f8g9h0 Merge branch 'release/v1.2.3' into main
...
* c383ae0 chore(global): initial commitIn the previous example, the
commit mergestrategy is used to get a visual representation of the flow but it is recommended to userebase mergeorsquash mergestrategy to get a linear history and as recommended in the release-please readme.
Conventional commits 
Commits should follow the specification of Conventional Commits, it is possible to add the VSCode extension to facilitate creating commits.
A PR must be made with a branch up-to-date with the develop branch (use rebase to keep your branch up-to-date, not merge) before requesting a fusion, and the fusion must be requested into develop.
Semmantic versioning 
Tags should follow the Semantic Versioning specification and should be managed in CI/CD using tools like:
- apps / packages - release-please and release-please-action.
- helm chart - chart-releaser and chart-releaser-action.
Tag patterns 
Pre-release 
Every push on the develop branch should trigger the creation or update of the pre-release PR.
| Tag type | Pattern | 
|---|---|
| Git | v1.2.3-rc.4 | 
| Npm | 1.2.3-rc.4 | 
| Docker | 1.2.3-rc.4 | 
| Helm | 1.2.3-rc.4 | 
Release 
Every push on the develop branch should trigger the creation or update of the release PR.
| Tag type | Pattern | 
|---|---|
| Git | v1.2.3 | 
| Npm | 1.2.3 | 
| Docker | 1.2.3 | 
| Helm | 1.2.3 | 
Helm 
Helm release should be triggered on every application pre-releease / release and should follow these rules:
- Helm chart could be bumped independently from the target app version (following semver).
- Helm chart should follow application version bump: - Increase major tag if application got major tag bump.
- Increase minor tag if application got minor tag bump.
- Increase patch tag if application got patch tag bump.
- Increase rc tag if application got rc tag bump.
 
Cheatsheet 
Conventional commits 
The commit message should be structured as follows:
<type>[(<scope>)][!]: <description>
[optional body]
[optional footer(s)]Types definition:
| Type | Description | 
|---|---|
| build | Changes that affect the build system or external dependencies. | 
| chore | Other changes that don't modify src or test files. | 
| ci | Changes to CI configuration files and scripts. | 
| docs | Documentation only changes. | 
| feat | A new feature. | 
| fix | A bug fix. | 
| perf | A code change that improves performance. | 
| refactor | A code change that neither foxes a bug nor adds a feature. | 
| revert | Reverts a previous commit. | 
| style | Changes that do not affect the meaning of the code. | 
| test | Adding missing tests or correcting existing tests. | 
Semmantic versioning 
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJORversion when you make incompatible API changes.
- MINORversion when you add functionality in a backward compatible manner.
- PATCHversion when you make backward compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the
MAJOR.MINOR.PATCHformat (ex:MAJOR.MINOR.PATCH-rc.RELEASE_CANDIDATE-1.2.3-rc.4).
Git 
Create a feature branch 
# Put the head on the `develop` branch
git checkout develop
# Pull `develop` branch updates
git pull
# Create and checkout on the branch `feat/my-feature-description`
git checkout -b feat/my-feature-description
# Add files to the staging area
git add -A
# Create a commit
git commit -m 'feat: my feature description'
# Push the branch to remote
git push --set-upstream origin feat/my-feature-description
# Create a pull request
gh pr create --fill --base develop --head feat/my-feature-descriptionCreate a hotfix branch 
# Put the head on the `main` branch
git checkout main
# Pull `main` branch updates
git pull
# Create and checkout on the branch `fix/my-hotfix-description`
git checkout -b fix/my-hotfix-description
# Add files to the staging area
git add -A
# Create a commit
git commit -m 'fix: my hotfix description'
# Push the branch to remote
git push --set-upstream origin fix/my-hotfix-description
# Create a pull request
gh pr create --fill --base main --head fix/my-hotfix-descriptionRebase a branch on another 
# Put the head on the `develop` branch
git checkout develop
# Pull `develop` branch updates
git pull
# Put the head on the `feat/my-feature-description` branch
git checkout feat/my-feature-description
# Rebase the `feat/my-feature-description` branch on the recently pulled `develop` branch
git rebase develop
## Optionaly resolve conflicts
# Push `feat/my-feature-description` updates to remote
git push --force-with-lease --force-if-includesAdd files to the staging area with interactive mode 
# Add all files interactively
git add -A -p
---
# Add given file interactively
git add -p path/to/file