I found this a while back, and thought it was interesting enough to save as a gist.

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

I've read this guide but...

I don't like to put too much emphasis on whether commit messages are first or third person, and whether it should start with a capital and/or end with a period...

I don't really see how that saves time or what kind of problems it's supposed to prevent.

Just start with the issue number and make sure the messages are clear.

I keep it pretty simple...

JIRA-123 Added featurename to componentname
JIRA-456 Bugfix for featurename in componentname
JIRA-789 NPM gardening and general project maintenance
or
JIRA-0 Readme update

Long descriptions live in JIRA; the zero-issue key (JIRA-0) is for really trivial stuff that doesn't impact functionality. Anything that changes the API or impacts functionality must have a real JIRA key.

I don't think it is important that everyone on the team has the exactly same style, however you should discuss some minimum requirements for a quality commit message, and make sure that during code review (ideally before merging a PR) the message meets the requirements.

I use the following style:

<imperative present-tense verb> <description> (<issue#>)

For example:

• fix mobile breakpoint on iOS 8 iPad Air (#12345)
• implement new side-bar layout (#54321)
• remove unused code (#99999)

Following the thinking that a commit applies a patch (to the history), and the comment is a label for the action, it allows a quick understanding when checking the git history, and also references the issue for a more detailed description of the changes. The rest is my personal taste.

The following article sums up what we follow, quite well!

Also do check out the past discussions we've had here on this topic:

that's from my style guide for my team

#<Main-Ticketnr> general description as headline #<other-ticket-references>
 - in short commits
 - this is optional
 - but if more things changed
 - we should list them explicit so we 
 - can actually see what the intention was

although I don't mind if the ticket number is in the end or the beginning. It's how the team works it just has to be there. all tier layers are in different repos so I have a git submodule structure, to keep track in gitlab I reference the backend ticket with the frontend tickets and architecture tickets. so you can jump between them if they correlate.

also the commit should be what happens when you apply it not about hat you did

changes  XYZ

not

changed XYZ

a somewhat related discussion:

hashnode.com/post/imperative-mood-vs-past-tense-w…

My reasoning is ofc debatable.

Describe what you did. That should make it easier for you and anyone looking at the project to understand what's been going on.

E.g. If you're fixing the docs, make sure to mention the section or the exact doc you edited. Here's my latest PR. I made it easier for the maintainer to understand what I've done, without him having to look at the diff. This is a rather dumb example, but imagine a larger doc with more changes.

Also, I tend to name the branches in a meaningful way, so that when you track CI builds, you know what's been going on.

E.g. My branch will have mm since those are my initials and short-description-of-what-is-being-updated

mm/fixing-documentation

Little things like that keep your team headache-free.

P.S. I just realized I didn't do exactly that in my example, sorry Sandeep 😂 However, when it's a major PR, I do follow all the rules.