René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[For Developers] Commit Guidelines","articleBody":"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:\r\n\r\n## Committing Format\r\n\r\nAll commits should follow [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/), a guideline followed by the entire project. What does this mean? All commits should be formatted like the following:\r\n\r\n```\r\n\u003ctype\u003e[optional scope]: \u003cdescription\u003e\r\n\r\n[optional body / long description]\r\n\r\n[optional footer(s)]\r\n```\r\n\r\nMost 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.\r\n\r\n## What are types?\r\n\r\nThe types represent what the commit is doing. For instance:\r\n\r\n- fix: A commit that patches a bug, but does not add any new features\r\n- feat: A commit that introduces a new type of feature to the code. This does not change anything, only adds on.\r\n- 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.\r\n- 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.)\r\n- docs: A commit that updates the docs. Not much else here.\r\n\r\nThere may be more types but ask RayhanADev.\r\n\r\n## Scopes?\r\n\r\nScopes 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:\r\n\r\n- workflow\r\n- contribution (`CONTRIBUTING.md`)\r\n- repo (general changes)\r\n- readme (for `README.md` file)\r\n\r\n## What about Pull Requests?\r\n\r\nThat'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.)\r\n\r\n## Semantic Version\r\n\r\nA common practice is to make this package follow SemVer or Semantic Versioning. Read over the specs [here](https://semver.org/). 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.\r\n\r\n## Closing\r\n\r\nI'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`](https://github.com/ReplAPI-it/ReplAPI.it-Python/blob/master/.github/CONTRIBUTING.md). Thanks!\r\n\r\n~ BD103 :D\r\n\r\n### Update\r\n\r\nMake the short description lowercase. I forgot to mention that!","author":{"url":"https://github.com/BD103","@type":"Person","name":"BD103"},"datePublished":"2021-06-01T14:14:05.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":16},"url":"https://github.com/17/ReplAPI.it-Python/issues/17"}