Replies: 3 comments
-
You can find informations on the net. I will try to resume it here : The conventional commit specification is a standardized way of writing commit messages that makes it easier to understand the changes made in a codebase. The format consists of a header, an optional body, and an optional footer, with each section separated by a blank line. The header has a specific format: [optional scope]: . The type field describes the type of change made, such as feat for a new feature, fix for a bug fix, or docs for documentation updates. The scope field is optional and describes the part of the codebase that was affected by the change. The description field provides a short summary of the change. The body section provides a more detailed explanation of the changes made, with each line wrapped at 72 characters. The footer section can include a number of optional fields, such as BREAKING CHANGE to indicate a breaking change made in the codebase, Closes or Fixes to link the commit to an issue or pull request, and Signed-off-by to indicate that the contributor has agreed to the project's Contributor License Agreement. |
Beta Was this translation helpful? Give feedback.
-
Example of a Commit guide line Example of a CONTRIBUTING.md |
Beta Was this translation helpful? Give feedback.
-
Sounds like a good idea. People can either discuss here or propose some PR on those two files. |
Beta Was this translation helpful? Give feedback.
-
Hello contributors,
I am proposing that we adopt the conventional commit specification for our commit messages.
This standard format will provide a consistent and clear way of communicating changes made to the codebase, making it easier for all team members to understand the intent behind each commit.
The conventional commit specification consists of a
header
, an optionalbody
, and an optionalfooter
, with each section separated by a blank line. The header has a specific format, including atype
, optionalscope
, anddescription
, to clearly identify the nature of the change made. Thebody
provides more detailed information about the change, and thefooter
can include additional information such as related issues or pull requests.Here is an example commit message using the conventional commit specification:
feat(users): add ability to reset passwords
This commit adds the ability for users to reset their passwords from the login screen. The reset password functionality is accessible by clicking on the "Forgot password?" link.
By adopting this specification, we can improve communication and collaboration among developers and make it easier to review and understand changes made to the codebase. Please let me know if you have any questions or concerns about this proposal.
Best regards,
Eric
Beta Was this translation helpful? Give feedback.
All reactions