Git Lint

Running Git Lint...

83dbad531d84a184e55cbb38c5b2a4e5fa5bcaee (Brooke Kuhlmann, 0 seconds ago): This is a bogus commit message that is also terribly long and will word wrap.
  Commit Body Presence Warning. Use minimum of 1 line (non-empty).
  Commit Subject Length Error. Use 72 characters or less.
  Commit Subject Prefix Error. Use: /Fixed/, /Added/, /Updated/, /Removed/, /Refactored/.
  Commit Subject Suffix Error. Avoid: /\./, /\?/, /\!/.

1 commit inspected. 4 issues detected (1 warning, 3 errors).

$HOME/.config/git-lint/configuration.yml

By default, most analyzers are enabled. Accepted values are true or false. If you wish to disable a analyzer, set it to false.

By default, most analyzers are set to error severity. If you wish to reduce the severity level of a analyzer, you can set it to warn instead. Here are the accepted values and what each means:

• warn: Will count as an issue and display a warning but will not cause the program/build to fail. Use this if you want to display issues as reminders or cautionary warnings.

• error: Will count as an issue, display error output, and cause the program/build to fail. Use this setting if you want to ensure bad commits are prevented.

Some analyzers support include or exclude lists. These lists can consist of strings, regular expressions, or a combination thereof. Regardless of your choice, all lists are automatically converted to regular expression for use by the analyzers. This means a string like "example" becomes /example/ and a regular expression of "\\AExample."` becomes `/\AExample./.

If you need help constructing complex regular expressions for these lists, try launching an IRB session and using Regexp.new or Regexp.escape to experiment with the types of words/phrases you want to turn into regular expressions. For purposes of the YAML configuration, these need to be expressed as strings with special characters escaped properly for internal conversion to a regular expression.

Ensures author name is properly capitalized. Example:

Ensures author email address exists. Git requires an author email when you use it for the first time too. This takes it a step further to ensure the email address loosely resembles an email address.

Ensures author name consists of, at least, a first and last name. Example:

Ensures commit body bullet lines are capitalized. Example:

In general, using ASCII Doc or Markdown syntax directly after a bullet will cause capitalization checks to be ignored because there can be valid reasons for wanting to avoid capitalization in those situations.

Ensures commit body bullets are delimited by a space. Example:

Ensures a single bullet is never used when a paragraph could be used instead. Example:

Ensures there is a leading, empty line, between the commit subject and body. Generally, this isn’t an issue but sometimes the Git CLI can be misused or a misconfigured Git editor will smash the subject line and start of the body as one run-on paragraph. Example:

Ensures each line of the commit body doesn’t extend beyond the maximum column limit.

Ensures each paragraph of the commit body is capitalized. Example:

Ensures non-descriptive words/phrases are avoided in order to keep commit message bodies informative and specific. The exclude list is case insensitive. Detection of excluded words/phrases is case insensitive as well. Example:

Ensures a minimum number of lines are present within the commit body. Lines with empty characters (i.e. whitespace, carriage returns, etc.) are considered to be empty.

Automatically ignores fixup! commits as they are not meant to have bodies.

Ensures commit body doesn’t use issue tracker shorthand. The exclude list defaults to GitHub Issues but can be customized for any issue tracker.

There are several reasons for excluding issue tracker links from commit bodies:

1. Not all issue trackers preserve issues (meaning they can be deleted). This makes make reading historic commits harder to understand why the change was made when the reference no longer works.

2. When disconnected from the internet or working on a laggy connection, it’s hard to understand why a commit was made when all you have is a shorthand issue reference with no supporting context.

3. During the course of a repository’s life, issue trackers can be replaced (rare but does happen). If the old issue tracker service is no longer in use, none of the commit body shorthand will be of any relevance.

Instead of using tracker shorthand syntax, take the time to write a short summary as to why the commit was made. Doing this will make it easier to understand why the commit was made, keeps the commit self-contained, and makes learning about/debugging the commit faster.

Ensures commit bodies don’t contain repeated words. Example:

Ensures all commit signatures are properly signed for improved security and validity of code being committed by various authors. By default, only "Good" signatures are allowed but you can expand this list if desired (although not recommended for security reasons). Valid options are:

• Bad (B)

• Error (E)

• Good (G)

• None (N)

• Revoked (R)

• Unknown (U)

• Expired (X)

• Expired Key (Y)

All of the above obtained when using the pretty formats as provided by Git Log.

Ensures the commit subject length is no more than 72 characters in length. This default is more lenient than the 50/72 rule as it gives one the ability to formulate a more descriptive subject line without being too wordy or suffer being word wrapped.

Automatically ignores fixup! or squash! commit prefixes when calculating subject length.

Ensures each commit subject uses consistent prefixes that explain what is being committed. The includes are case sensitive and default to the following prefixes:

• Fixed - Identifies what was fixed. The commit should be as small as possible and consist of changes to implementation and spec only. In some cases this might be a single line change. The important point is the change is applied to existing code which corrects behavior that wasn’t properly implemented earlier.

• Removed - Identifies what was removed. The commit should be as small as possible and consist only of removed lines/files from the existing implementation. This might also mean breaking changes requiring the publishing of a major version release in the future.

• Added - Identifies what was added. The commit should be as small as possible and consist of implementation and spec. Otherwise, it might be a change to an existing file which adds new behavior.

• Updated - Identifies what was updated. The commit should be as small as possible and not add or fix existing behavior. This can sometimes be a grey area but is typically reserved for updates to documentation, code comments, dependencies, etc.

• Refactored - Identifies what was refactored. Refactoring is for changing code structure without changing observable behavior. The commit should be as small as possible and not mix multiple kinds of changes at once. Refactored code should never break existing implementation behavior or corresponding specs because, if that happens, then one of the other four prefixes is what you want to use instead.

In practice, it is quite rare to need a prefix other than what has been detailed above to explain what is being committed. These prefixes are not only short and easy to remember but also have the added benefit of categorizing the commits for building release notes, change logs, etc. This becomes handy when coupled with another tool, Milestoner, for producing consistent project milestones and Git tag histories. For a deeper dive on subject prefixes and good commit messages in general, please read about commit anatomy to learn more. 🎉

Each prefix is delimited by a space which is the default setting but can be customized if desired. Whatever you choose for a delimiter will not affect Git’s special bang prefixes as described in the tip below.

💡 This analyzer automatically ignores amend!, fixup!, or squash! commit prefixes when used as a Git Hook in order to not disturb interactive rebase workflows.

Ensures commit subjects are suffixed consistently. The exclude list is case sensitive and prevents the use of punctuation. This is handy when coupled with a tool, like Milestoner, which automates project milestone releases.

Ensures commit subjects don’t contain repeated words. Example:

Ensures collaborator name is properly capitalized. Example:

Ensures collaborator email address is valid for commit trailer.

Ensures collaborator trailer key is correct format.

Ensures collaborator name consists of, at least, a first and last name. Example:

Ensures commit trailer keys are not duplicated. Example:

Ensures format trailer key is correct format.

Ensures format trailer value is a valid value.

Ensures issue trailer key is correct format.

Ensures issue trailer value is correct format.

Ensures milestone trailer key is correct format.

Ensures milestone trailer value is correct format for semantic versioning purposes.

Ensures milestone trailers are alphabetically sorted.

Ensures reviewer trailer key is correct format.

Ensures reviewer trailer value is correct format for linking/referencing the code review system.

Ensures commit signer trailer name is properly capitalized.

Ensures commit signer trailer email is properly capitalized.

Ensures signer trailer key is correct format.

Ensures signer name consists of, at least, a first and last name.

Ensures tracker trailer key is correct format.

Ensures tracker trailer key is correct format.

Your default branch configuration is respected no matter if it is set globally or locally. If the default branch is not set then Git Lint will fall back to master for backwards compatibility. When the next major version is released, the default branch fallback will change from master to main. You can set your default branch at any time by running the following from the command line:

💡 When setting your default branch, ensure you use a consistent Git configuration across all of your environments.

This gem supports Git Hooks.

It is highly recommended you manage Git Hooks as global scripts as it’ll reduce project maintenance costs for you. To configure global Git Hooks, add the following to your $HOME/.gitconfig:

Then you can customize Git Hooks for all of your projects. Check out these examples.

If a global configuration is not desired, you can add Git Hooks at a per project level by editing any of the scripts within the .git/hooks directory of the repository.

rake git_lint

Detection and configuration happens automatically by checking the CIRCLECI environment variable. No additional setup required!

Detection happens automatically by checking the GITHUB_ACTIONS environment variable as supplied by the GitHub environment. The only configuration required is to add a .github/workflows/git_lint.yml to your repository with the following contents:

The above will ensure Git Lint runs as an additional check on each Pull Request.

Detection and configuration happens automatically by checking the NETLIFY environment variable. No additional setup required!