github/hedgedoc
1
0
Fork 0
mirror of https://github.com/hedgedoc/hedgedoc.git synced 2024-11-21 17:26:29 -05:00
Code Issues Projects Releases Packages Wiki Activity

Add commit guidelines to contribution docs

Browse source 
To ensure maintainability,
commit guidelines are added to our contribution documentation.
They include notes on commit structure and the commit message,
which evolved from issues that were encountered while developing.

Signed-off-by: David Mehren <git@herrmehren.de>
This commit is contained in:
David Mehren 2021-01-30 17:36:19 +01:00
parent 22aaa956a7
commit c42871be66
No known key found for this signature in database
GPG key ID: 185982BA4C42B7C3
1 changed files with 23 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
CONTRIBUTING.md
View file

@ -70,10 +70,32 @@ like `git config --global alias.ci 'commit -s'`. Now you can commit with `git ci
## Submitting a Pull Request
1. Submit an issue describing your proposed change. We will try to respond to your issue promptly.
2. Fork this repo, develop and test your code changes. Ensure you signed all your commits (see above for details).
2. Fork this repo, develop and test your code changes. Ensure you follow the commit guidelines (see below)
and signed all your commits (see above for details).
3. Submit a pull request against this repo's `develop` branch.
4. Your branch may be merged once all configured checks pass.
### Commit guidelines
- Follow these rules when writing a commit message:
1. Separate subject from body with a blank line
2. Limit the subject line to 50 characters
3. If you worked on a specific part of the application, you can prefix your commit message with that Example: "
MediaService: Get media backend from configuration"
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
These are inspired by https://chris.beams.io/posts/git-commit/
- Split your change into small, atomic commits. This helps reviewing the changes and enables the use of `git bisect`.
- Ensure the commit history is easy to follow. Use `git rebase -i` to sort and squash your commits if neccessary.
- If your branch includes fixup commits (like "Fix typo...", "Fix tests..."), use `git rebase -i` to clean them up
before submitting a pull request.
- When refactoring something, take care to not include any functional changes into the same commit. Mixing refactoring
and functional changes makes it hard to find the cause of regressions.
[code-of-conduct]: ./CODE-OF-CONDUCT.md
[community-forum]: https://community.hedgedoc.org