# 💡 Skip this line if you already have the public certificate installed.gem cert --add<(curl --compressed --location https://alchemists.io/gems.pem)gem install git-lint --trust-policy HighSecurity

gem install 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: /Added /, /Updated /, /Fixed /, /Removed /, or /Refactored /.  Commit Subject Suffix Error. Avoid: /\./, /\?/, /\!/.1 commit inspected. 4 issues detected (1 warning, 3 errors).

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

Enablement

By default, most analyzers are enabled. Accepted values aretrue orfalse. If you wish todisable a analyzer, set it tofalse.

Severity

By default, most analyzers are set toerror severity. If you wish to reduce the severity level ofa analyzer, you can set it towarn 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 tofail. 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. Usethis setting if you want to ensure bad commits are prevented.

Regular Expressions

Some analyzers supportinclude orexclude lists. These lists can consist of strings, regularexpressions, or a combination thereof. Regardless of your choice, all lists are automaticallyconverted 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 IRBsession and usingRegexp.new orRegexp.escape to experiment with the types of words/phrases youwant to turn into regular expressions.For purposes of the YAML configuration, these need to beexpressed as strings with special characters escaped properly for internal conversion to a regularexpression.

Commit Author Capitalization

Ensures author name is properly capitalized. Example:

Commit Author Email

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

Commit Author Name

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

Commit Body Bullet Capitalization

Ensures commit body bullet lines are capitalized. Example:

In general, usingASCII Doc orMarkdown 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.

Commit Body Bullet Delimiter

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

Commit Body Bullet Only

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

Commit Body Leading Line

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

Commit Body Line Length

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

Commit Body Paragraph Capitalization

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

ASCII Doc andMarkdown code blocks are ignored since a paragraph that only consists of a code block is common practice. For ASCII Doc, this includes the following to be separate paragraphs if desired:

• Audio and video links

• Image links

• Links

• Cross references

Commit Body Phrase

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

Commit Body Presence

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 ignoresfixup! commits as they are not meant to have bodies.

Commit Body Tracker Shorthand

Ensures commit body doesn’t use issue tracker shorthand. The exclude list defaults to GitHub Issuesbut 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 readinghistoric 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 whya 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 willbe of any relevance.

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

Commit Body Word Repeat

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

Commit Signature

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 byGit Log.

Commit Subject Length

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

Automatically ignoresfixup! orsquash! commit prefixes when calculating subject length.

Commit Subject Prefix

Ensures each commit subject uses consistent prefixes that explainwhat is being committed. Theincludes arecase sensitive and default to the following prefixes:

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

• Updated - Identifies what was updated. The commit should be as small as possible andnot addor fix existing behavior. This can sometimes be a grey area but is typically reserved for updatesto documentation, code comments, dependencies, etc.

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

• Removed - Identifies what was removed. The commit should be as small as possible and consistonly of removed lines/files from the existing implementation. This might also mean breakingchanges requiring the publishing of amajor version release in the future.

• Refactored - Identifies what was refactored.Refactoring is for changing codestructure without changing observable behavior. The commit should be as small as possible andnot mix multiple kinds of changes at once. Refactored code should never break existingimplementation behavior or corresponding specs because, if that happens, then one of the otherfour 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 explainwhat is being committed. These prefixes are not only short and easy to remember but also have theadded benefit of categorizing the commits for building release notes, change logs, etc. This becomeshandy when coupled with another tool,Milestoner, for producing consistent projectmilestones and Git tag histories. For a deeper dive on subject prefixes and good commit messages ingeneral, please read aboutcommit 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 thetip below.

💡 This analyzer automatically ignoresamend!,fixup!, orsquash! commit prefixes when used asa Git Hook in order to not disturb interactive rebase workflows.

Commit Subject Suffix

Ensures commit subjects are suffixed consistently. The exclude listis case sensitive and preventsthe use of punctuation. This is handy when coupled with a tool, likeMilestoner, which automates project milestonereleases.

Commit Subject Word Repeat

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

Commit Trailer Collaborator Capitalization

Ensures collaborator name is properly capitalized. Example:

Commit Trailer Collaborator Email

Ensures collaborator email address is valid for commit trailer.

Commit Trailer Collaborator Key

Ensures collaborator trailer key is correct format.

Commit Trailer Collaborator Name

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

Commit Trailer Duplicate

Ensures commit trailer keys are not duplicated. Example:

Commit Trailer Format Key

Ensures format trailer key is correct format.

Commit Trailer Format Value

Ensures format trailer value is a valid value.

Commit Trailer Issue Key

Ensures issue trailer key is correct format.

Commit Trailer Issue Value

Ensures issue trailer value is correct format.

Commit Trailer Milestone Key

Ensures milestone trailer key is correct format.

Commit Trailer Milestone Value

Ensures milestone trailer value is correct format forsemantic versioning purposes.

Commit Trailer Order

Ensures milestone trailers are alphabetically sorted.

Commit Trailer Reviewer Key

Ensures reviewer trailer key is correct format.

Commit Trailer Reviewer Value

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

Commit Trailer Signer Capitalization

Ensures commit signer trailer name is properly capitalized.

Commit Trailer Signer Email

Ensures commit signer trailer email is properly capitalized.

Commit Trailer Signer Key

Ensures signer trailer key is correct format.

Commit Trailer Signer Name

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

Commit Trailer Tracker Key

Ensures tracker trailer key is correct format.

Commit Trailer Tracker Value

Ensures tracker trailer key is correct format.

Default Branch

Your default branch configuration is respected no matter if it is set globally or locally. If thedefault branch isnot set then Git Lint will fall back tomain. 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 ofyour environments.

Hooks

This gem supportsGit Hooks.

It ishighly recommended you manage Git Hooks as global scripts as it’ll reduce projectmaintenance 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 theseexamples.

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

rake git_lint

Circle CI

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

GitHub Actions

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

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

Netlify CI

Detection and configuration happens automatically by checking theNETLIFY environment variable. Noadditional setup required!

git clone https://github.com/bkuhlmann/git-lintcd git-lintbin/setup

bin/console

bin/rake