[For Developers] Commit Guidelines

[BD103]

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!

[kokonut27]

Nice and ok.

[darkdarcool]

Noice. Also I made it grammatically correct to not capitalize my name today

[kokonut27]

lol noice

[BD103]

I updated the message. I forgot to mention that short descriptions should be lowercase.

[kokonut27]

Oh, ok. I'll do that from now on :)

[BD103]

Nice

[darkdarcool]

Me too

[rayhanadev]

@BD103 nice initiative :)

[rayhanadev]

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.

• If you have a question/comment about a Commit, make a comment on the commit itself or open a discussion.
• If you have a question/comment about an Issue, make a comment on the same issue or open a discussion.
• If you have a question/comment about a pull request, make a comment on the pull request or the commit that merges it in.
• If you just generally need help, use the threads on the Repl.

[rayhanadev]

I myself am unsure what to do for PRs

@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 feat: add x to the 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.

[BD103]

Got it!

[darkdarcool]

:)

[iop3]

isn't feat basically covered by docs? @BD103. Cuz you said:

docs: A commit that updates the docs. Not much else here.

and in feat you said:

feat: A commit that introduces a new type of feature to the code. This does not change anything, only adds on.

isn't feat updating the docs too?

[iop3]

oh i just realized ur status is:

🍌 Inactive for the time being, I'll be back in a week or two!

im so dumb

[BD103]

@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

[iop3]

Ah, I see thanks!