[EN] Semantische Git Commits: Dein Schlüssel zu saubererem Code und besserer Zusammenarbeit

Hello everyone,

do you know that? You browse through your project’s Git history and come across commit messages like “Fix” or “Changes”. In the worst case, you will only see “asdfasdf”. This might be funny at the moment, but when you start chasing a bug or trying to understand why a certain change was made, it becomes a nightmare.

This is exactly where Semantic Git Commit Messages come into play. They are not an end in themselves, but a powerful tool to massively improve the quality of your code, the efficiency of team collaboration and the traceability of development. Let’s take a closer look at why this is so important and how we can integrate it into our everyday lives.

Why semantic commits at all?

Some may think: “Oh, it’s just a commit, who cares?”. But the reality is that well-written commit messages provide enormous value:

• Better traceability: You can see what a commit does in seconds without having to read the code. This is worth its weight in gold when debugging or doing code reviews.
• Automated changelogs: Tools can generate automatic changelogs from your commits. Imagine, a release log almost writes itself!
• Simplified Reverts: If a commit causes problems, you can roll it back more specifically and confidently because you know exactly what type of change it was.
• Clearer Code Reviews: Reviewers understand the intent behind a PR more quickly.
• Tool support: CI/CD pipelines can perform specific actions based on commit types (e.g. release a patch version on fix: commits).
• Improved team communication: Everyone speaks the same “language” in the commit history. This promotes understanding and avoids misunderstandings.

In short: Semantic commits make life easier – for yourself, for your team and for your future selves.

The structure of a semantic commit message

The most common and proven scheme for semantic commit messages is based on the Conventional Commits specification. It is easy to remember and yet offers enough flexibility.

A commit message typically consists of three parts: Type, Scope (optional) and Description. Optionally a Body and a Footer can be added.

<Typ>(<Scope>): <Beschreibung>

[Optionaler Body]

[Optionaler Footer(s)]

The guy

The type is the most important thing. It describes the type of change. Here are the most common types:

• feat: A new functionality or feature (e.g. feat: User registration added).
• fix: A bug fix (e.g. fix: Fixed crash with empty input fields).
• docs: Changes to the documentation (e.g. docs: README updated).
• style: Changes that affect the code style but have no effect on the logic (e.g. style: formatting of imports adjusted).
• refactor: A code change that neither adds a feature nor fixes a bug (e.g. refactor: outsource authentication logic to separate service).
• test: Add or customize tests (e.g. test: Added unit tests for UserService).
• chore: Maintenance tasks affecting the build process or utility tools (e.g. chore: dependency 'lombok' updated).
• build: Changes affecting the build process or external dependencies (e.g. build: Dockerfile optimized).
• ci: Changes to the CI/CD configuration (e.g. ci: Added GitHub Actions workflow for deployments).
• perf: A code change that improves performance (e.g. perf: database query optimized for faster loading times).

Der Scope (optional)

The Scope indicates which part of the code base the change affects. This is helpful for quickly understanding the context of the change.

Examples: (auth), (ui), (database), (api), (project-x).

The description (subject)

The Description is a short, concise summary of the change.

• Should be written in the present and imperative tense (e.g. “adds”, “fixes”, “changes”).
• No longer than 50-72 characters.
• No period at the end.

Example: feat(user management): Added endpoint to fetch all users

Body (optional)

If the description is not enough to fully explain the change, you can add a more detailed Body. Here you can describe details, reasons and effects. Pay attention to an empty line between subject and body.

Footer (optional)

The Footer is often used for references to issue trackers or breaking changes.

• Closes #123: Linked to an issue in the issue tracker.
• Breaks: <description of breaking change>: Indicates an incompatible change.

Your workflow for semantic commits

That sounds like a lot, but with a few simple steps it will quickly become a habit:

1. Atomic Commits: Try to keep your commits as small and focused as possible. One commit = one logical change.
2. Commitizen or similar tools: There are tools like Commitizen that interactively guide you through the creation of a semantic commit message. This takes the pressure off and ensures compliance with the convention.
3. Linter for Commit Messages: You can also configure Git hooks or CI tools that validate your commit messages and warn you if they don’t follow the convention.
4. Team agreement: Agree within the team which types you will use and which rules apply to scopes. Consistency is key here!

Conclusion

Semantic Git commit messages may seem like extra work at first glance. But the effort quickly pays off. They dramatically improve the readability of your commit history, make maintenance and collaboration easier, and make your projects more sustainable. Start small, experiment and integrate it into your workflow step by step. You will notice the difference!

Have you already had experience with semantic commits? Which types do you use most often? Let me know!