How I Shared My Websiteβs Code
GitHub, Semantic Versioning, and Conventional Commits
Although itβs nice that people can read my posts and watch my videos, sometimes itβs better to be able to look at the source code itself. So, Iβve made the rational decision to share my code on GitHub a bit earlier than usual.
There wonβt be much coding here, so itβs going to be a noticeably short post.
Youβll see whyβ¦
Creating a GitHub Project from WebStorm
I want to create a new GitHub project from the website that I made in my previous DevLog: https://bayanbennett.medium.com/how-i-started-a-website-d2a34547bc57
In the git menu, select GitHub, and then Share Project on GitHub. A modal should appear that looks like the following:
Name the repository what you wish and click on the SHARE button.
And thatβs how easy it is to put your code on GitHub from WebStorm. The repository is here: https://github.com/BayanBennett/reference.bayanbennett.com
If any readers would like a more specific tutorial, please let me know.
Now everyone can watch the codebase evolve!
About Versioning
I suspect that most readers of this post will already know a bit about version control systems (VCS) and semantic versioning (SemVer), but for those who donβt, hereβs a summary.
Most projects that Iβve had the pleasure of being a part of have been stored in a VCS called Git. VCSs are responsible for creating and managing the differences between snapshots of code.
Another way of expressing the state of your code in comparison to other states is SemVer. Usually, itβs not ideal to have different SemVers for each VCS commit. Sometimes code changes are small and have no impact on the functioning of the project.
Users of Node Package Manager (NPM) may already be well familiar with SemVer. A quick refresher straight from the NPM documentation is below.
Letβs say your first release was version 1.0.0:
- Fixes (patch) would increment the last digit (e.g.
1.0.1) - Non-breaking features (minor revision) would increment the middle digit (e.g.
1.1.0) - Breaking changes (major revision) would increment the first digit (e.g.
2.0.0)
Conventional Commits
One of the systems that makes it easy to implement semantic versioning is something called Conventional Commits. I was introduced to this a couple of years ago, and I havenβt used anything else since.
Implementation is straightforward and simplifies the process of managing versioning. Conventional commits provide a way of structuring commit messages that can be used to automate version incrementation. When a batch of commits are pushed to a release branch (e.g. master, main, next, etc.), their messages are inspected, and the appropriate version increment is determined.
For example, here are a couple commit messages taken directly from the Conventional Commits home page:
feat: allow provided config object to extend other configs
BREAKING CHANGE: `extends` key in config file is now used for extending other config files
or
docs: correct spelling of CHANGELOG
Aside from their linguistic differences, different actions could be triggered based on the type of keyword used. Hereβs an example list of types that CommitLint uses:
build
chore
ci
docs
feat
fix
perf
refactor
revert
style
testAll these types could trigger different actions. Some of them could be configured to not make changes to the SemVer. An instance where this may be the case is with refactoring, where no additional features or fixes are produced.
The keywords and their actions are completely configurable. Keywords can be added, removed, and their corresponding actions changed.
When to Implement Conventional Commits
Implementing Conventional Commits for reference.bayanbennett.com is a bit early, considering it isnβt even released yet.
The best time would be whenever your project is used by others, it can help them become better informed about changes to your project.
TL; DR
Creating a GitHub project is easy with WebStorm. Semantic Versioning with Conventional Commits are a powerful combination.
