Hello, everyone! We have some new people on the repo, specifically @darkdarcool and @JBYT27. Because of this, I would like to highlight the standards for committing to the repo. Let's get started:
Committing Format
All commits should follow Conventional Commits, a guideline followed by the entire project. What does this mean? All commits should be formatted like the following:
<type>[optional scope]: <description>
[optional body / long description]
[optional footer(s)]
Most of the time, Replit only supports a short description. Because of this, you would probably only insert line 1 of that sample. If you are making a commit on Github, then the long description is supported.
What are types?
The types represent what the commit is doing. For instance:
- fix: A commit that patches a bug, but does not add any new features
- feat: A commit that introduces a new type of feature to the code. This does not change anything, only adds on.
- BREAKING CHANGE: (or you could also add an
!
after the type / scope) introduces a change to the API. This means that it breaks pre-existing code.
- chore: A commit that updates something in the repo that does not directly correlate to the code. (For instance updating README.md, changing Github Actions, etc.)
- docs: A commit that updates the docs. Not much else here.
There may be more types but ask RayhanADev.
Scopes?
Scopes represent a specific section to the type. They don't have to be anything specific and don't have to have been used before. They just help a reviewer easily tell where the change occurred in case the description is obscure. Some used scopes have been:
- workflow
- contribution (
CONTRIBUTING.md
)
- repo (general changes)
- readme (for
README.md
file)
What about Pull Requests?
That's a very good question. I myself am unsure what to do for PRs, but I assume that they follow the same format. Combine all the commits, and find the most important. (Breaking is more important than feat, and fix is more important than docs.)
Semantic Version
A common practice is to make this package follow SemVer or Semantic Versioning. Read over the specs here. They go in direct correlation with Conventional Commits. You guys will not probably have to worry about this, as I will be the one who packages and releases the versions. It's just nice to know.
Closing
I'm sorry for the word wall. After noticing the commit history was a mess I knew I had to do something, though. Please raise any questions in the comments, and remember to also read over CONTRIBUTING.md
. Thanks!
~ BD103 :D
Update
Make the short description lowercase. I forgot to mention that!
Type: DOCUMENTATION