|
|
|
---
|
|
|
|
title: Developer guide
|
|
|
|
---
|
|
|
|
|
|
|
|
# Table of contents
|
|
|
|
[[_TOC_]]
|
|
|
|
|
| ... | ... | @@ -79,4 +80,59 @@ Example issue title : |
|
|
|
|
|
|
|
[feature] Implement algorithm Foo bar
|
|
|
|
|
|
|
|
Select an issue template (feature request or bug report) and fill all fields as clearly and concisely as possible. |
|
|
\ No newline at end of file |
|
|
|
Select an issue template (feature request or bug report) and fill all fields as clearly and concisely as possible.
|
|
|
|
|
|
|
|
# Push rules
|
|
|
|
|
|
|
|
The online repository has rules on the format of commit messages as well as branch names.
|
|
|
|
|
|
|
|
## Branch names
|
|
|
|
Branch names should always be created from issues, and the Gitlab repository settings are such that their suggested name should always match the branch name push rule.
|
|
|
|
The branch name rule in the public repository is set with the following regular expression:
|
|
|
|
|
|
|
|
`^(main|develop|(\d+)-hotfix-.+|(\d+)-feature-.*|release-v\d+\.\d+\.\d+)$`
|
|
|
|
|
|
|
|
Examples of valid branch names are listed below. You can test the regular expression above by copy/pasting it in https://regex101.com/ and tweaking your text until it matches the expression.
|
|
|
|
|
|
|
|
Valid branch names:
|
|
|
|
- main
|
|
|
|
- develop
|
|
|
|
- \<issue number\>-hotfix-\<arbitrary text\> (e.g. 2-hotfix-pvgis-api)
|
|
|
|
- \<issue number\>-feature-\<issue title\> (e.g. : 69-feature-grassim-refactoring, generated from issue #69 )
|
|
|
|
- release-v\<major version\>.\<minor version\>.\<patch version\> (e.g. release-v1.2.4)
|
|
|
|
|
|
|
|
## Commit rule
|
|
|
|
This rule exists to prevent cryptic commit messages, often pushed when in a rush and thus degrading the traceability of the commits in the repository's history.
|
|
|
|
|
|
|
|
A commit message should comprise the following :
|
|
|
|
- title line with 3 possibilities:
|
|
|
|
1. standard commit: commit type in square brackets (e.g. \[feature\] or any of the list of commit types) followed by the title, briefly describing the content : "[feature] Apply multiplying factor to GHI"
|
|
|
|
2. merge commit from a Gitlab merge request : "Merge branch 'source' into 'target' "
|
|
|
|
3. merge commit from remote into local branch : "Merge branch '\<branch name\>' of gitlab.uliege.be:deal-public/branch into branch"
|
|
|
|
- blank line
|
|
|
|
- commit message body
|
|
|
|
- possibly "Closes # \<issue number\>" but this is automatically handled in Gitlab merge requests
|
|
|
|
|
|
|
|
|
|
|
|
The commit message rule is set with the following regular expression:
|
|
|
|
|
|
|
|
`^(?:\[(feature|fix|chore|refactor|docs|style|test|perf|ci|build|revert)\] .+|Merge branch '.*' .+)\n\n(.+)`
|
|
|
|
|
|
|
|
Examples of valid commit messages are listed below. You can test the regular expression above by copy/pasting it in https://regex101.com/ and tweaking your text until it matches the expression.
|
|
|
|
|
|
|
|
### Standard commit message
|
|
|
|
|
|
|
|
[fix] Error in azimut/elevation computation
|
|
|
|
|
|
|
|
The x and y component were reversed in foo.py, method get_azimut_elevation(). I fixed it by [blablabla]...]. Now the results are correct as validated by foobar other method.
|
|
|
|
|
|
|
|
|
|
|
|
### Merge request commit message
|
|
|
|
Merge branch '69-feature-grassim-refactoring' into 'develop'
|
|
|
|
|
|
|
|
Describe the new feature, refer relevant commits, etc.
|
|
|
|
|
|
|
|
### Merge remote branch into local branch
|
|
|
|
Merge branch '\<branch name\>' of gitlab.uliege.be:deal-public/branch into branch
|
|
|
|
|
|
|
|
Some description. |
|
|
\ No newline at end of file |
