openharmony/third_party_libsnd
1
0
Fork 0
mirror of https://gitee.com/openharmony/third_party_libsnd synced 2024-11-23 01:49:53 +00:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Update commit message contributing guidlines

Browse Source 
Related to #705.
This commit is contained in:
evpobr 2021-02-17 13:33:15 +05:00
parent 5d5eb6fed5
commit d7e17811b1
1 changed files with 24 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
CONTRIBUTING.md
View File

@ -18,7 +18,30 @@
* Patches should always be submitted via a either Github "pull request" or a
via emailed patches created using "git format-patch".
* Patches for new features should include tests and documentation.
* Commit messages should follow the ["How to Write a Git Commit Message"](https://chris.beams.io/posts/git-commit/) guide.
* Commit messages should follow the ["How to Write a Git Commit Message"](https://chris.beams.io/posts/git-commit/) guide:
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. Capitalize the subject line
4. Do not end the subject line with a period
5. Use the imperative mood in the subject line
6. Wrap the body at 72 characters
7. Use the body to explain what and why vs. how
Additional rule: the commit message may contain a prefix. The prefix must
contain the name of the feature or source file related to the commit and must
end with a colon followed by the message body.
Examples of good commit messages:
1. Fix typo
2. Update CHANGELOG.md
3. Add ACT file format support
4. ogg_vorbis: Fix granule position when seeking Vorbis streams
Examples of bad commit messages:
1. Fixed bug (rule 5)
2. update docs (rule 3)
3. Add very cool feature. (rule 4)
* Patches to fix bugs should either pass all tests, or modify the tests in some
sane way.
* When a new feature is added for a particular file format and that feature