{"slug": "comment-nommer-ses-branches-et-ses-messages-de-commit", "title": "Comment nommer ses branches et ses messages de commit ?", "summary": "This article provides guidelines for naming Git branches and writing commit messages. Branch names should follow a `<type>/<name>/<issue_ID>` format using kebab-case, while commit messages should adhere to the Conventional Commits standard with a structured format including type, scope, subject, body, and footer. These conventions improve codebase clarity, enable semantic versioning, and allow for automation of tasks like changelog generation.", "body_md": "Inspiré par [codeheroes](https://www.codeheroes.fr/2020/06/29/git-comment-nommer-ses-branches-et-ses-commits/)\n\n# Règles relatives aux messages de Commit\n## Nommer les branches\nEn dehors des branches develop et master, comment nommer nos autres branches ?\n\nRien de bien sorcier, nous allons simplement indiquer le type de la branche suivi du nom de celle-ci, optionnellement nous pouvons ajouter le numéro du ticket. Le tout doit être séparé par le caractère slash \"/\" :\n```\n<type>/<name>/<issue_ID>\n```\n## Les types de branches\n\n|   Commit type              | Desciption                                    | Emoji |\n|:---------------------------|:----------------------------------------------|:------|\n| feature                    | Ajout d’une nouvelle fonctionnalité           | ✨    |\n| bugfix                     | Correction d’un bug                           | 🐛    |\n| hotfix                     | Correction d’un bug critique                  | 🚑    |\n| chore                      | Nettoyage du code                             | 🧼    |\n| experiment                 | Expérimentation de fonctionnalités            | 🚨    |\n\n## Le nom de la branche\nLe nom de la branche décrit succinctement le but de celle-ci. Certaines règles doivent être respectées :\n- Le nom doit faire moins de 50 caractères\n- Le nom doit respecter la convention kebab-case (les mots doivent être en minuscule et liés par des tirets “-“)\n\n## Le numéro de ticket\nPour le suivi de vos tickets, que ce soit sur Github, Gitlab ou tout autre outil comme JIRA par exemple,\nil peut être utile d’ajouter le numéro de ceux-ci dans le nom de vos branches. \nIl est ainsi possible par exemple de fermer automatiquement vos tickets lorsque la branche sera “merger”.\n\n## Quelques exemples\nVoyons quelques exemples de noms de branches pour mieux comprendre :\n```\nfeature/add-users-controller\nhotfix/profile-page-error/621\nexperiment/try-api-key\nchore/remove-deprecated-method/924\n```\n# Nommer les messages de commits\nLe message d’un commit doit être clair et concis, il doit indiquer ce qui a été modifié et la raison de cette modification.\nLa convention de nommage la plus utilisée est la “Conventional Commits“.\nL’avantage de respecter cette convention, outre le fait de rendre plus compréhensibles vos commits,\nest de permettre de respecter la sémantique de versions (SemVer) et d’automatiser certaines tâches \n(comme la génération d’un fichier Changelog par exemple).\n## Format des messages\nLe format du message est le suivant :\n```\n<type>(<scope>): <subject>\n```\n```\n<body>\n<BLANK LINE>\n<footer>\n```\n## Voyons plus en détail chacune des parties du message. \n\n### Le type\nLe type du commit décrit l’origine du changement. Il peut prendre différentes valeurs :\n|   Commit type              | Desciption                                    | Emoji |\n|:---------------------------|:----------------------------------------------|:------|\n| feat                       | Ajout d’une nouvelle fonctionnalité           | ✨    |\n| fix                        | Correction d’un bug                           | 🐛    |\n| build                      | Changement lié au système de build ou qui concerne les dépendances | 🚧    |\n| deploy                     | Deploy project                                | 🚀    |\n| ci                         | Changement concernant le système d’intégration et de déploiement continu | 👷    |\n| docs                       | Ajout ou modification de documentation        | 📚    |\n| perf                       | Amélioration des performances                 | 🐎    |\n| refactor                   | Modification n’ajoutant pas de fonctionnalités ni de correction de bug | 🔨    |\n| style                      | Changement lié au style du code               | 🎨    |\n| test                       | Ajout ou modification de tests                | 🚨    |\n| revert                     |  Annulation d’un précédent commit             | ⏪    |\n| chore                      | Toute autre modification                      | 🚨    |\n| security                   | Fix security issue                            | 🔒    |\n[[...](https://gist.github.com/bizouarn/e2c850f95fda6832567b7172da3d24bb)]\n\nPour chacun des types, vous pouvez également utiliser un système d’emoji comme gitmoji.\n\n### Le scope\n\nCet élément facultatif indique simplement le contexte du commit. Il s’agit des composants de notre projet, voici une liste non exhaustive :\n\n- controller\n- route\n- middleware\n- view\n- config\n- service\n- etc.\n\n### Le sujet\n\nLe sujet décrit succinctement la modification. Certaines règles doivent être respectées :\n- Le sujet doit faire moins de 50 caractères.\n- Les verbes doivent être à l’impératif (add, update, change, remove, etc.).\n- La première lettre ne doit pas être en majuscule.\n- Le sujet ne doit pas se terminer par un point.\n\n### Le corps du message\n\nLe corps du message, qui est optionnel, doit contenir les raisons de la modification ou tout simplement donner plus détails sur le commit. \nIl peut également indiquer les changements importants (breaking changes). \nCelui-ci doit faire moins de 100 caractères.\n\n### Le footer\n\nLe footer est également facultatif, celui-ci est surtout utilisé pour faire référence aux tickets (issue) de Github ou Gitlab \npar exemple que le commit règle ou aux changements importants (breaking changes). \nCelui-ci doit faire moins de 100 caractères.\n\n### Quelques exemples\n```\nrefactor(repository): remove deprecated method\n \nBREAKING CHANGE: findById and findByPrimary methods have been removed.\n \nCloses #78\n```\n```\nfix(controller): use the correct HTTP code\n \nUse the HTTP error 403 instead of 401 if the user is authenticated.\n```\n", "url": "https://wpnews.pro/news/comment-nommer-ses-branches-et-ses-messages-de-commit", "canonical_source": "https://gist.github.com/bizouarn/48e6d3661cf2cdb90732fbac91ff7f56", "published_at": "2022-03-22 14:06:22+00:00", "updated_at": "2026-05-22 17:10:46.604288+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["Github", "Gitlab", "JIRA", "Conventional Commits", "SemVer"], "alternates": {"html": "https://wpnews.pro/news/comment-nommer-ses-branches-et-ses-messages-de-commit", "markdown": "https://wpnews.pro/news/comment-nommer-ses-branches-et-ses-messages-de-commit.md", "text": "https://wpnews.pro/news/comment-nommer-ses-branches-et-ses-messages-de-commit.txt", "jsonld": "https://wpnews.pro/news/comment-nommer-ses-branches-et-ses-messages-de-commit.jsonld"}}