Git Workflow

Git Workflow

Branching strategy

We have three branches, the Main, the Develop and the Integration branchs. Those are permanent branches.

Branch	Use
develop	Daily work. Push often.
integration	Staging. We merge develop into it when we deploy to staging.
main	Finished features that could go to production. We merge integration into it.

feature branch -> develop -> integration -> main

Rules:

• No direct commits on main or develop or integration.
• All changes must go through a Pull Request.
• All working branches are created from develop and merged back into develop.

Branch naming

feature/: For new feature development release/: For release preparation hotfix/: For urgent production fixes bugfix/: For fixes to the integration branch

How do we name them on the git?

For each ticket, we work on a short branch made from develop: feature/<ticket>-<short-name>, for example feature/38-add-indicator-values. As we can see, it's taking the order of what we do on those branches, then a / and after that, we put the number of the issue from the Projects, and the name of the task.

• kebab-case only.
• no spaces, no accents.
• short and explicit names.

Commit conventions

Based on Conventional Commits.

Format:

type: short description

Allowed types:

  feat - new feature.
  fix - bug fix or linter fix.
  style - CSS / UI only.
  refactor - refactor without functional change.
  docs - documentation.
  test - tests.
  save - intention or session end.
  chore - Config, scripts, build

Examples:

• feat - #ticket-number/add hero landing section.
• fix - #ticket-number/correct svg aria-label.
• style - #ticket-number/improve about animation.
• docs - #ticket-number/document git workflow.
• save - #ticket-number/end of the day, saving header and navbar section.

Rules:

1 commit = 1 intention.
clear and concise message (under 72 characters).
written in English, use the imperative.
avoid update, test, wip, final.

Pull requests

All changes must be merged via a Pull Request into developp.

PR checklist:

• clear and explicit title.
• description includes What/Why (you can add your commits).
• project runs locally without errors.
• at least 2 reviews before merge.
• Two fellows developpers are doing review.
• The one who presses the merge button will be the last who approved the pull request

Recommended merge strategy:

• Squash and merge.
• Definition of Done (Git).

A task is considered Done when:

• the PR is merged into dev.
• code review is completed.
• build runs successfully.
• no sensitive files are committed (.env, secrets).

Rules

• We don't merge directely, we do that from a Pull Request: for every branches as we encourage the code review with everyone.
• Never commit secrets or generated files
• Never rewrite shared history
• Pull before you push.