go to prefix list directly

Why Even Bother?

Open one of your old repositories and type git log in the terminal. Chances are, you have no idea what you meant by update four months ago.

And no, commit messages like changes, a, or pls just work are not only unhelpful to you but also annoying for your teammates. Clear and informative commit messages make a big difference, especially in collaborative projects.

Use the imperative mood in subject lines (e.g., add german language). It should sound like you are giving an order or request.
added german language would be wrong.

Here are the 5 key points:

• Write clear and good commit messages that are easy to read.
• Use prefixes like 'feat:' or 'fix:' at the start of your commit messages.
• Do not put a period (dot) at the end of your commit message.
• Keep commit messages short, not more than 50 characters.
• Use a commit body if needed.

What are commit prefixes?

In short, they make your commits look pretty ✨.

Imagine a commit message like this: fixed typo. This brings up questions: Where was the typo fixed? Will it break the API?

To make things clearer, use prefixes. In our example, the typo was in the dog images API, changing the query parameter from ?naem=<NAME> to ?name=<NAME>. This is a breaking change because old code using the wrong parameter will stop working.

A good commit prefix for this change could be: fix(api/dogs)!: query param typo.

Lets break it down:

Jokes aside:

fix: what is the type of the commit.
(api/dogs): where was the change (optional).
!: is it a breaking change.
query param typo: the actual commit message

In general this is how your commits should be structured:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

So here are some example:

feat(lang): add german language
feat(auth): add OAuth support
docs(readme): add installation instructions

This is how it looks on github:

fix: test

fix(this): test

All commit prefixes

• fix: Bug fix
• feat: a new feature or enhancement
• chore: updating dependencies or setting up build tools etc
• ci: change to CI like GitHub Actions
• refactor: code refactoring without adding new features or fixing bugs
• docs: documentation-only changes (README etc)
• style: changes related to formatting such as code style adjustments, and whitespace changes (not css changes)
• perf: performance improvements without changing existing functionality
• test: unit tests etc
• revert: revert a commit

How they look on github: