-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[For Developers] Commit Guidelines #17
Comments
Nice and ok. |
Noice. Also I made it grammatically correct to not capitalize my name today |
lol noice |
I updated the message. I forgot to mention that short descriptions should be lowercase. |
Oh, ok. I'll do that from now on :) |
Nice |
Me too |
@BD103 nice initiative :) |
I'd like to add that in addition issues on this repository (or any repo in general lol) should not be used to make comments or ask questions, especially if its for help or about another commit/issue/pr.
|
@BD103 you can either leave it as Merge... (the autogenerated description) or make it the name of the PR. Example: A pr that adds new features to an api In addition use squash merges (I'll try to set it up automatically if I can). That way commit history isn't too clogged. |
Got it! |
:) |
isn't feat basically covered by docs? @BD103. Cuz you said:
and in feat you said:
isn't feat updating the docs too? |
oh i just realized ur status is:
|
@iop3 I just happened to check this. Feat changes the package code itself while docs is specific for documenting the code. If you created a new function you would use feat. If you added Sphinx or edited a README file, that would be considered docs |
Ah, I see thanks! |
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:
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:
!
after the type / scope) introduces a change to the API. This means that it breaks pre-existing code.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:
CONTRIBUTING.md
)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!
The text was updated successfully, but these errors were encountered: