Table des matières
Notes git - Convention commit - Bien nommer ses commits
Voir :
Voir :
Type
Must be one of the following:
- feat: A new feature
- fix: A bug fix
- docs: Documentation only changes
- style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
- refactor: A code change that neither fixes a bug nor adds a feature
- perf: A code change that improves performance
- test: Adding missing or correcting existing tests
- chore: Changes to the build process or auxiliary tools and libraries such as documentation generation
Voir : 11 tips for writing a good Git commit message
https://github.com/cisagov/development-guide
Voir aussi :
Pull request example
Type of change
- Patch fixing an issue (non-breaking change)
- New functionality (non-breaking change)
- Functionality enhancement or optimization (non-breaking change)
- Breaking change (patch or feature) that might cause side effects breaking part of the Software
Checklist
- I have followed the coding style guidelines provided by Centreon
- I have commented my code, especially hard-to-understand areas of the PR.
- I have rebased my development branch on the base branch (develop).
- I have provide data or shown output displaying the result of this code in the plugin area concerned.
Type of change
- Patch fixing an issue (non-breaking change)
- New functionality (non-breaking change)
- Functionality enhancement or optimization (non-breaking change)
- Breaking change (patch or feature) that might cause side effects breaking part of the Software
Checklist
- I have followed the coding style guidelines provided by Centreon
- I have commented my code, especially hard-to-understand areas of the PR.
- I have rebased my development branch on the base branch (develop).
- In case of a new plugin, I have created the new packaging directory accordingly.
- I have implemented automated tests related to my commits.
- Data used for automated tests are anonymized.
- I have reviewed all the help messages in all the .pm files I have modified.
- All sentences begin with a capital letter.
- All sentences end with a period.
- I am able to understand all the help messages, if not, exchange with the PO or TW to rewrite them.
- After having created the PR, I will make sure that all the tests provided in this PR have run and passed.
It shouldn't exist (but it does)
Est-ce qu'il y a une convention Git de message de commit pour dire “c'est trop de la m…. je ne cautionne pas, et j'ai trop honte de voir mon nom gravé dans l'historique des commits” ? Il y a bien GLWTPL, mais ça c'est pour la licence.
J'ai vu des horreurs dans le code, déjà que j'aime pas les films d'horreurs mais là je suis choqué. et pas le temps de refactorer
Proposition :
- It shouldn't exist but it does.
- Abomination
- Aberration
- It saddens me to see this
- It should be forbidden / SHOULD BE BANNED
Autres
Règle d'organisation du dépôt
Règle d'organisation du dépôt
Les dépôts sont organisés selon une arborescence qui respecte les règles suivantes :
- le nom des répertoires est le plus explicite possible et ne contient pas d'accents et d'espaces (remplacer par un souligné),
- l'encodage des fichiers textes et des tables (type .csv) est en UTF-8,
- dans la mesure du possible, chaque nœud de l'arborescence contient un fichier Readme.md (en markdown) qui présente brièvement les répertoires
Source : https://sourcesup.renater.fr/www/si-snot/5_MO_VersionnementGit.html
Exemple de un unique dépôt pour plusieurs exécutables :
