How I Shared My Website's Code | DevLog 002

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

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
test

All 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.