Lintje is written to promote communication between people within Git commits. Lintje wants you to write detailed commit subjects and messages. Your team reading these commits during reviews and debug sessions 2+ months from now will thank you.
Lintje checks for commits like “Fix bug” and instead prefers commits that explain changes in more detail. Explain why the change was necessary, what alternatives were considered and why this solution was chosen. This will provide much needed context to future readers so they understand what kind of constraints the commit was made under.
Inspiration for Lintje’s rules:
Read the rules pages for all the rules Lintje checks and how to fix them.
Lintje does not enforce a particular workflow. Commits don’t require a template. Commits don’t need to be perfect on the first try, which is why I recommend not exiting the commit process when Lintje encounters an issue.
You can make atomic commits or you can make no commits. Make as many “WIP” commits as needed while you’re fixing a bug or working on a feature.
When it’s time to share your work with your team, or push it to a public repository, go back to these “WIP” commits and rewrite the Git history. Rewriting the branch history you will squash commits, split commits and rewrite commit messages to tell a detailed story in smaller parts. This way the final result of your work is more readable by your team and any future debuggers.
Lintje does not actively promote machine parsing of commit subjects and messages for the purposes of generating changelogs automatically.
The audiences of commits and changelogs are different. Commits are written for people working on a project and changelogs are written for people using the project. In my opinion a changelog entry should not be based on a Git commit, but instead be managed with another tool such as Changesets, which can also generate changelogs automatically.