PretendoNetwork/.profile
Watch
1
0
Fork
You've already forked .profile
 0
Code Issues Projects Releases Packages Wiki Activity

chore: added "feat" to commit message section

Browse source
This commit is contained in:
Jonathan Barrow 2024-05-01 18:07:56 -04:00
commit da06a6353c
No known key found for this signature in database
GPG key ID: E86E9FE9049C741F
1 changed files with 1 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

2
.github/CONTRIBUTING.md vendored
View file

@ -71,7 +71,7 @@ Besides the changes themselves, commits are the most important part of contribut
The scale and scope of a commit should be reasonable. Do not commit for every line when making multiple changes, for example. However you should not include many unrelated changes in a single commit. By limiting the scope of the commit we can ensure that if any regressions or new bugs are introduced we can easily revert those changes without the need for major refactors or reimplementations. Limiting the scale of commits also makes review of the changes easier and faster. The scale and scope of a commit should be reasonable. Do not commit for every line when making multiple changes, for example. However you should not include many unrelated changes in a single commit. By limiting the scope of the commit we can ensure that if any regressions or new bugs are introduced we can easily revert those changes without the need for major refactors or reimplementations. Limiting the scale of commits also makes review of the changes easier and faster.
## Messages ## Messages
Commit messages should adequately explain the changes in the commit. Messages like "Updated file.md" and "spelling error" should not be used. Nonsense messages such as "oops" or "fixed" are especially not allowed. Commit messages should, at minimum, be in the format `type: message` where `type` represents the type or scope of the changes (`chore`, `docs`, `bug-fix`, etc.) and `message` is the actual changes. Unless the word is from the codebase and starts with a capital letter (such as an exported Go struct), the `message` should be lowercase. We also recommend using both "subject" and "body" commits. This can be achieved through the git CLI by using multiple `-m`/`--message` flags. For example `git commit -m "short subject" -m "longer description of the changes"`. Commit messages should adequately explain the changes in the commit. Messages like "Updated file.md" and "spelling error" should not be used. Nonsense messages such as "oops" or "fixed" are especially not allowed. Commit messages should, at minimum, be in the format `type: message` where `type` represents the type or scope of the changes (`feat`, `chore`, `docs`, `bug-fix`, etc.) and `message` is the actual changes. Unless the word is from the codebase and starts with a capital letter (such as an exported Go struct), the `message` should be lowercase. We also recommend using both "subject" and "body" commits. This can be achieved through the git CLI by using multiple `-m`/`--message` flags. For example `git commit -m "short subject" -m "longer description of the changes"`.
The following are examples of good commit messages: The following are examples of good commit messages: