--- ---

Git Commits Style Guide

Protocols for authoring Git commits for DocOps Lab projects

General Style (Conventional Commits)

DocOps Lab loosely follows the Conventional Commits specification for Git commit messages.

Enforcement is not strict, but using Conventional Commits style is encouraged for consistency and clarity.

Most DocOps Lab projects do not base Changelog/Release Notes generation on commit messages.

The basic outline for a Conventional Commit message is:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Description

The commit description should be concise and to the point, summarizing the change in 50 characters or less.

Use the past tense rather than imperative mood (e.g., "Added feature X" instead of "Add feature X").

Commit Types

  • Use present-tense descriptive verbs (“adds widget”, not “added” or “add”)

  • feat: …​ for new features OR improvements

  • fix: …​ for bugfixes

  • chore: …​ for version bumps and sundry tasks with no product impact

  • docs: …​ for documentation changes

  • test: …​ for test code changes

  • refactor: …​ for code restructuring with no functional changes

  • style: …​ for formatting, missing semi-colons, etc; no functional changes

  • perf: …​ for performance improvements

  • auto: …​ for changes to CI/CD pipelines and build system

Commit Body Conventions

  • Use the body to explain what and why vs. how.

  • Reference issues and pull requests as needed.

  • Use bullet points (- text) and paragraphs as needed for clarity.

  • Do not hard-wrap lines, but do:

    • use 1-sentence per line

    • keep sentences short