Try   HackMD

Conventional Git Commit Messages and Linting

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Do you want to follow Conventional Commits and want to enforce a rule such that your team also follows it? In this article, You will learn how to enforce Conventional Commenting rule prior to commit your Angular or Nrwl.Nx Monorepo code in GitHub. Now a days all of open source library like ngrx platform they started following precise rules over how git commit messages must be formatted. This leads to more readable messages that are easy to follow when looking through the project history.

What is Conventional Commit?

The Conventional Commits specification is a lightweight convention on top of commit messages. It provides an easy set of rules for creating an explicit commit history; which makes it easier to write automated tools on top of. This convention dovetails with SemVer (Semantic Versioning), by describing the features, fixes, and breaking changes made in commit messages.

Why is Conventional Commit?

We will use the Conventional Commits specification. So that it will make easy to write automated tools on top of it. Example if you follow conventional commits then you can write some automation to

  • Bump version of the package.json file based on commit message format.
  • You can generate the Changelog automatically.

If you are convinced then continue reading to setup this rule in your angular or any nod.js project.

Examples of Conventional Message Format

Commit message with scope & no body
docs(readme): correct spelling of package

Commit message with scope, description and breaking change footer

feat(logger): need to depend on websocket library
BREAKING CHANGE: the api parameters changed

Learn more here.

Conventional Commit Message Format

We will use conventional commit to enforce the discipline.

The commit message should be structured as follows:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer than 120 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

Conventional Commit Type

Type
Must be one of the following:

  • build: Changes that affect the build system or external dependencies (example scopes: webpack, karma, npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: azuredevops.yaml, Travis, Circle, BrowserStack, SauceLabs)
  • docs: Documentation only changes
  • feat: A new feature
  • fix: A bug fix
  • perf: A code change that improves performance
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)
  • test: Adding missing tests or correcting existing tests

Conventional Commit Scope

The scope should be the name of the npm package affected (as perceived by the person reading the changelog generated from commit messages.
Example if you have a project where you have publishable libraries & applications. Then you can use their project names.

Apps: admin, client, dashboard
Lib: logger, layout, messaging

The following is the list of supported scopes:

  • admin
  • client
  • dashboard
  • logger
  • layout
  • messaging

Conventional Commit Subject

The subject contains a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot (.) at the end

Conventional Commit Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word `BREAKING CHANGE:`` with a space or two newlines. The rest of the commit message is then used for this.

Example:

feat(scope): commit message

BREAKING CHANGES:

Describe breaking changes here

BEFORE:

Previous code example here

AFTER:

New code example here

Lets learn how can we automate these rules in our own project such that no team member can violate this rules.

Commitlint Node Package

We will use commitlint node package to enforce the constraints for commit message format.

We will also use husky to run the linting rules before commit.

Run below script to install commitlint & husky.

npm i -D husky @commitlint/cli @commitlint/config-conventional

Adding rules to package.json

 "commitlint": {
    "extends": [
      "./node_modules/@commitlint/config-conventional"
    ],
    "rules": {
      "subject-case": [
        0
      ],
      "header-max-length": [
        0,
        "always",
        120
      ]
    }
  },
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },

What will happen here is that every time a commit is attempted, it will get linted based on the conventional commit message rules. The developer will get an error if they deviate. This is painful to start with but it becomes second nature after a while!

Testing Conventional Commit Rules

Add comment adding commit rules and try to commit

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Notice you see error.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Commit error

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Lets fix our comment as per Conventional Commit Rule. Change the comment like below & commit

build: added new script for linting

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Now you should be able to commit your code.

Note we can successfully commit and push our code.

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

Conclusion

Now you learn how can you use conventional commits and enforce this rule in your project.
In my next article I will explain how can you apply some automation on this project. Like bumping package.json versions automatically, generating change log etc. So stay tuned.

Become full stack developer 💻

If you want to become full stack developer and grow your carrier as new software
developer or Lead Developer/Architect. Consider subscribing to our full stack
development training programs. We have All-Access Monthly membership plans and
you will get unlimited access to all of our video courses, slides, source code &
Monthly video calls.

  • Please subscribe to
    All-Access Membership PRO plan to
    access current and future angular, node.js and related courses.
  • Please subscribe to
    All-Access Membership ELITE plan to
    get everything from PRO plan. Additionally, you will get access to monthly
    live Q&A video call with Rupesh and you can ask doubts/questions and get more
    help, tips and tricks.

You bright future is waiting for you so visit today
FullstackMaster and allow me to help you to board
on your dream software company as a Developer,Architect or Lead Engineer role.

💖 Say 👋 to me!

Rupesh Tiwari
www.rupeshtiwari.com
✉️ Email Rupesh
Founder of Fullstack Master
Last changed by 
 
Rupesh Tiwari
I help students & professionals to become full stack web developer in just 90 days by giving free lessons and live coding sessions. www.fullstackmaster.net
0
816

Read more

How to improve Reliability in the cloud?

How to improve Reliability in the cloud? Did you get a phone call from your customer saying they want to improve their application reliability while you move their workload to the cloud? If yes then continue reading this article. I will use Microsoft Azure to explain the Reliability concept and its improvement steps. You can certainly do the same in Google Cloud or Amazon AWS. What is Reliability? Well reliability is a derived concept. Basically you want your application to be available for your customer. Also you should ask what latency is acceptable for your application. If your application is slower or normal, your application users should not keep retrying to finish any transaction. How should your application fidelity be while your application is slow and not rendering properly. So in order to define reliability of your application you have to answer how much your application should be Available and what is your Latency that you want for your application. Reliability = Availability + Latency So basically reliability is something your Business has to define. You must talk to your customer and understand what kind of business they are running, what problem they want to solve, who are the target users for the application.

Nov 29, 2021
Cost Optimization with AWS Spot EC2 Instances 

Creating cost optimized highly scalable cloud architecture is challenging but it is possible! Using Spot Amazon Elastic Compute Cloud (Amazon EC2) instances you can save up to 90% of on-demand pricing. In this article you will learn what spot instances and what should be your strategy to use spot instances. Additionally, I will give you scenarios where most of the customers are using spot instances. Amazon EC2 Purchasing Options Amazon Elastic Compute Cloud (Amazon EC2) offers 3 purchasing options: On-Demand Reserved Instances Saving Plans

Nov 10, 2021
Cloud Security Defense In-Depth Azure Approach 

Cloud Security Defense In-Depth Azure Approach In a traditional data center you create one perimeter, secure them by installing firewall, WAF, SIEMS etc. and have 100% confidence that the data center is secure. However, when you migrate to cloud then your VPC or Virtual Network is not 100% secure you have to not only secure your perimeter however, inside of perimeter you have to take care of security. Since it&apos;s a public cloud you have to be more cautious and make sure whatever workload or source code you are moving to is cloud aware. There are various best practices at each level you have to take care of in order to secure your cloud. What is Defense in-depth? There is a concept of Defense in-depth which makes sure that at each level there is security in-place which makes your cloud data center almost 100% secure. However, it needs continuous awareness, assessments and audits. In this article let&#x2019;s explore how Azure helps us to secure data centers in the cloud. Defense in-depth design of azure services and capabilities to help you secure, manage and monitor your cloud data, infrastructure, compute Azure offers unified security management and advanced threat protection for your cloud, on-premise data centers or both. When you want to secure your cloud you should think of securing from the physical layer till your data layer.

Nov 5, 2021
What is Multi-Cloud and Multi-Cloud Strategy?

What is Multi-Cloud and Multi-Cloud Strategy? Cloud itself is complex so why are customers bothering about multi-cloud at all? Why not just take google cloud and deploy all of your workload and be happy? Well it&apos;s just like you should not put all eggs in one basket.Let&apos;s explore Multi-Cloud in this article. According to a VMWare Customer survey 2 out of 3 customers are using multi-cloud so it is very important for you to be aware of the challenges and strategies of multi-cloud. Doing Multi-Cloud is possible but not easy and comes with some tradeoffs. While we are going towards microservices architecture each microservice can use any kind of technology stack. Example one service can use raven db then another service can use Microsoft SQL server. So if you have that kind of workload in your architecture that means you are already investing in multiple database vendors in your technology portfolio. Similarly you may create your workloads in multiple cloud providers such as Microsoft, Google or Amazon and create multi-cloud situations. In this article you will learn what is multi-cloud, why you do multi-cloud and what is the multi-cloud strategy? So stay tuned and keep scrolling. Who is the cloud provider? Cloud Provider is a company who provides online delivery of IT services via internet on an on-demand basis and pay as you go model. Example of cloud providers are: Google Cloud

Nov 2, 2021
Read more from Rupesh Tiwari
Published on HackMD