Skip to main content

Commit Rules

When it comes to version control in software development, committing code changes is a critical process that allows developers to track and manage code changes over time. However, committing code changes should be done following certain rules to ensure that the codebase is well-maintained and easily understandable for other developers.

Knowledge about Semantic Versioning​

To understand commit rules further, first, we need to know about semantic versioning. Semantic versioning is a standard for assigning version numbers to software. The standard consists of three digits: MAJOR.MINOR.PATCH.

  1. MAJOR is used to indicate significant changes in the software that can affect stability or compatibility with previous versions.
  2. MINOR is used to indicate the addition of features that are still compatible with previous versions.
  3. PATCH is used to indicate bug fixes or minor issues in the software.

In commit rules, the use of semantic versioning helps to determine the type of change in the software and makes it easier for developers to understand the type of commit made. Additionally, the use of semantic versioning also simplifies the testing and maintenance processes in the software.

Example of a commit Message​

example of a commit Message that follows 7 rules of semantic commit message

example:

type: description of commit message

  1. feat: A new feature or functionality added to the codebase.​

feat: Implement Google OAuth2 login

  1. fix: A bug fix or correction made to the codebase.​

fix: Resolve issue with Google login not redirecting properly

  1. docs: Changes or updates made to the documentation of the codebase.​

docs: Update README.md with instructions for setting up Google login

  1. style: Changes made to the code's formatting, such as indentation, whitespace, or semi-colons.​

style: Apply consistent formatting to Google login button

  1. refactor: Code changes made to improve the code structure, but without adding new functionality or fixing a bug.​

refactor: Extract Google login functionality into separate module

  1. test: Changes or additions made to the testing suite, such as adding new tests or updating existing ones.​

test: Write unit tests for Google login functionality

chore: Update dependencies for Google login package

or you can use the specific of semantic commit message​

example:

type(scope): description of commit message

  1. feat(scope): description - A new feature has been added to the codebase​

feat(login): Add option to remember user login for Google accounts

  1. fix(scope): description - A bug or error has been fixed in the codebase.​

fix(login): Fix issue with Google login redirect

  1. docs(scope): description - Documentation has been added or updated in the codebase.​

docs(login): Update README with instructions for Google login configuration

  1. style(scope): description - Changes have been made to the codebase's formatting or style, such as adding whitespace or renaming variables.​

style: Apply consistent formatting to Google login button

  1. refactor(scope): description - Code has been refactored or reorganized without adding any new features or fixing any bugs.​

refactor: Extract Google login functionality into separate module

  1. test(scope): description - New tests have been added or existing tests have been modified.​

test: Write unit tests for Google login functionality

  1. chore(scope): description - Changes have been made to the codebase that do not affect the functionality of the code, such as updating dependencies or configuring build tools.​

chore: Update dependencies for Google login package


  • Semantic versioning for update​

This commit introduces a minor feature that enables users to log in to the app with their Google account. The changes made are backward-compatible with previous versions of the app, following the rules of semantic versioning.

update: MINOR version bump from 1.2.3 to 1.3.0

Implementation of commit rules​

  1. git add .​

  2. git commit -m "feat(file): add mdx file for documentation"​

    in this example we use the specific of semantic commit message with the scope of file changes! Deployment

  3. git push origin [branch-name]​


Conclusion​

To ensure that other developers can easily understand the commit message, it is recommended to use semantic commit messages. Therefore, let's rewrite the statement as follows: "For the commit message to be easily understood by other developers, it is advisable to use semantic commit messages."