As being a developer, we commit our work and push to github. Initially, we overlook the way how we enter the commit. Now, I am writing this blog so you can understand how it should be written. It is essential because in collaborating projects it maintain the status of project with readability and understandability of the Git commit.
First, lets look to its basic structure. Below is its structure.
<type>([optional scope]): <short description>
[optional body]
[optional footer]Here’s what each part means.
- type: A compulsory part of the structure, indicating the nature of the change
- optional scope: Provides context for the commit, typically used when a change affects a specific module or feature (data-quality, spark, data-warehouse, etl, docker, airflow).
- short description: A concise summary of the commit
- optional body: A more detailed description
- optional footer: Can including breaking changes or reference issues/ticket numbers
Types of Conventional Commits:
- feat: A new feature.
- fix: A bug fix.
- docs: Documentation changes.
- style: Styling changes (e.g. formatting)
- refactor: Changes that neither fixes a bug no adds a feature.
- test: A new feature.
- chore: Other changes that don’t modify src or test files.
- perf: performance improvements.
- build: Changes that affect the build system or external dependencies.
- ci: Changes to CI configuration files and scripts.
- revert: Reverts a previous commit.
Conventional Commits — Examples
Adding a new feature
feat: add customer lifetime value model
This model calculates the lifetime value of customers using transaction data.References Issues or Tickets:
fix: handle divide by zero in customer lifetime
The issue occured when calculating the customer lifetime value based on purchase history.
Fixes: #123Above are the basic example how you write your commits. Hope you find this post resourceful and ac-knowledgeable. If you do have any query regarding this post you can comment in this post. Thank you and have wonderful day.