Skip to content
Snippets Groups Projects
  • Hugo Trentesaux's avatar
    ef73a0d0
    improve documentation (!101) · ef73a0d0
    Hugo Trentesaux authored and Éloïs's avatar Éloïs committed
    * fix
    
    * doc(end2end): detail test users
    
    * doc(all): update docker tag
    
    update docker image name from 0.2.0 to 0.3.0
    use "docker compose" everywhere instead of "docker-compose"
    improve table of content
    fix layout
    
    * doc(all): improve docs
    
    add logo to readme
    add table of content
    rewording
    complete
    
    * doc(all): fix typos
    ef73a0d0
    History
    improve documentation (!101)
    Hugo Trentesaux authored and Éloïs's avatar Éloïs committed
    * fix
    
    * doc(end2end): detail test users
    
    * doc(all): update docker tag
    
    update docker image name from 0.2.0 to 0.3.0
    use "docker compose" everywhere instead of "docker-compose"
    improve table of content
    fix layout
    
    * doc(all): improve docs
    
    add logo to readme
    add table of content
    rewording
    complete
    
    * doc(all): fix typos
git-conventions.md 6.46 KiB

Duniter git conventions

TL;DR summary of this page, workflow instructions

The summary gives an overview of the rules described below. Reading it will help you to dive into the details.

  • draft work must be prefixed by "WIP" (work in progress)
  • the naming of final commits must comply with the template type(scope): action subject
  • one should communicate with developers through dedicated spaces
  • integrating a contribution can only be done via a merge request on our gitlab option and since the following critera are fullfilled
    • branch up to date with master branch (except hotfixes, see the hotfix section)
    • idiomatic code formatting, automated tests passed successfully
    • clean commit history, understandable and concise
    • contribution approved by a reviewer

Naming commits

Every commit must comply with conventional commit specification v1.0.0.

The commit name has to be meaningful in the context of commit history reread. It should not make reference to a specific MR or discussion. Among other, commit history is used in changlogs and to track the project progress, that's why it has to be self-explanatory. If you have a new need, please contact the main developers to add a type together.

Update strategy

We only use rebases, merges are strictly fordbidden !

Every time the master branch is updated, you must rebase each of your working branch on it. For each of them: