Apply conventional commit style on your project

Hello 🙋‍♂️, today I´m going to write about Conventional Commits (as you can see in the title). I've always wondered if there was a standardization with commits. I think this standardization is necessary and it can make our life easier

Git is widely used across the software engineering world to build software because it helps to keep the history of changes in our codebase throughout the build of software by a team.

After performing some code changes (editing files, adding a new file, and deleting files), we must commit to adding our change in Git history. A commit is usually a message that summarizes what we did on the codebase.

What is conventional commit?

From the conventional commit specification website:

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.

Commits should have the following structure:

git commit -m <type>[optional scope]: <subject>

[optional description]

[optional footer(s)]

Type

It indicates the type of commit. Is it a feature, a fix, a test, a refactoring, tooling, etc...

The recommended values are:

Types	Target	Description
`feat`	Features	A new feature
`fix`	Bug Fixes	A bug fix
`docs`	Documentation	Documentation only changes
`style`	Styles	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
`refactor`	Code Refactoring	A code change that neither fixes a bug nor adds a feature
`perf`	Performance Improvements	A code change that improves performance
`test`	Tests	Adding missing tests or correcting existing tests
`build`	Builds	Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
`ci`	Continuous Integrations	Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
`chore`	Chores	Other changes that don't modify src or test files
`revert`	Reverts	Reverts a previous commit
`enh`	Enhance	Changes that improve a feature.

Scope

Is an optional part of the format
Allowed Scopes depends on the specific project
Don’t use issue identifiers as scopes
Breaking changes should be indicated by an ! before the : in the subject line e.g. feat(api)!: remove status endpoint which is an optional part of the format

It indicates the scope in your application concerned by the commit. It is not required, and you are responsible for the definition of values. Some examples: authentication database settings translation

Subject

The subject contains a succinct description of the change, a short summary of the things you have done in the commit.

Is a mandatory part of the format
Use the imperative, present tense: “change” not “changed” nor “changes”. Think of This commit will <subject>

Also for better messages you can have these things too:

Don't capitalize the first letter
No dot (.) at the end

Any information about Breaking Changes and is also the place to Reference Issues that this commit refers to.

Is an optional part of the format
optionally reference an issue by its id.
Breaking Changes should start with the word BREAKING CHANGES: followed by space or two newlines. The rest of the commit message is then used for this.

Breaking changes

All breaking changes have to be mentioned in footer with the description of the change, justification and migration notes.

BREAKING CHANGE: isolate scope bindings definition has changed and
    the inject option for the directive controller injection was removed.
    
    To migrate the code follow the example below:
    
    Before:
    
    scope: {
      myAttr: 'attribute',
      myBind: 'bind',
      myExpression: 'expression',
      myEval: 'evaluate',
      myAccessor: 'accessor'
    }
    
    After:
    
    scope: {
      myAttr: '@',
      myBind: '@',
      myExpression: '&',
      // myEval - usually not useful, but in cases where the expression is assignable, you can use '='
      myAccessor: '=' // in directive's template change myAccessor() to myAccessor
    }
    
    The removed `inject` wasn't generaly useful for directives so there should be no code using it.

Referencing issues

You can mention closed bugs or issues with keyword “Closes”

Closes #234

or reference a ticket with “Refs” keyword:

Refs: #123 #234

Example of valid messages

feat(translation): add support for french language

style(database): delete useless code inside the generated migration

build(core): release version 2.1.0

feat(authentication): replace the authentication provider fr om xxx to yyy


BREAKING CHANGE: ticket enpoints no longer supports list all entites.
refers to JIRA-1337
Co-authored-by: teco, pinas, pavelito

perf(payments): improve payment processing by 500ms

feat(database): onUrlChange event (popstate/hashchange/polling)

Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available

BREAKING CHANGE: $browser.onHashChange, which was removed (use onUrlChange instead)

Best Practices

Here are some recommended best practices for writing Git commit messages:

Keep it concise: A commit message should be a short summary of the changes made, ideally no more than 50 characters.
Use the imperative mood: Start the commit message with an imperative verb, such as Add, Fix, Update, or Remove.
Provide details in the body: After the summary line, provide additional details in the commit message body, including any relevant context, motivation, or explanation of the changes made.
Separate subject and body with a blank line: Use a blank line between the subject and the body of the commit message.
Use proper formatting: Use proper formatting, such as bullet points or paragraphs, to make the commit message easy to read and understand.
Reference issue numbers: If the commit message is related to a specific issue or ticket, reference the issue number in the message body or commit message.
Be consistent: Use consistent formatting and style across all commit messages in the project.

Conclusion

Conventional Commit Messages offer a straightforward yet impactful approach to version control, promoting clarity and consistency in documenting code changes.

By adhering to this standardized format, developers can enhance communication, simplify project management, and automate essential tasks.

Whether you’re a solo coder or part of a collaborative team, embracing Conventional Commit Messages can significantly improve your Git workflow and contribute to more efficient and effective software development.