Git commit message templates you can copy

09 Oct 2025

in Better Commit Policy, Bitbucket Cloud, Jira Cloud, Tutorial

• 10 min read

A Git commit message template is a predefined format that defines what a commit message must contain: a work item key, a type prefix, a description, so every developer on the team writes commits the same way.

Whether you're a developer, adapting to your team's expected commit message standards, or you're an engineering manager looking to introduce new audit-ready rules across your developer organization, this Git commit message template collection is a practical starting point.

A consistent, audit-ready commit history is a foundation for traceability, audit readiness, and efficient collaboration, which are a must for teams working in regulated industries, like defense, healthcare, or finance.

But even in fast-paced software teams, commit messages that follow a predictable pattern help:

Understand what changed and why, even after many years
Automate or expedite releases, compliance reviews and audits
Catch violations as early as commit time, using commit policies on developers local environments

The templates below cover the most common commit types for regulated and fast-moving teams. Each one is ready to copy, with notes on what to enforce and how.

Engineering managers and dev leads can use this as blueprint to create your team's Git commit message conventions.

Use and customize the Git commit templates below in your specific environment. Find notes on why they work and how to enforce them for automated compliance.

10 Git commit message templates to copy

1. Security patch example (Finance)

SEC-431 fix(crypto): update OpenSSL to 3.0.13 to address CVE-2025-231

✅ Why it works:

Starts with a Jira work item key (SEC-431)
Clearly marks the change type (fix)
Uses a subsystem tag (crypto)
References a CVE for audit traceability

This follows the "require Jira work item key" and "commit message length convention" rules.

💡 How to verify?

2. New feature deployment (Healthcare)

HLT-2109 feat(api): add endpoint for patient medication history retrieval

Add new /api/v1/patients/{id}/medications endpoint returning medication list with timestamps and source system IDs.

Data privacy: returns only permitted fields, enforces authz (scope: medication:read), and enables audit logging for PHI access.

Tests: TEST-MED-101 (unit) and TEST-MED-201 (integration)

✅ Why it works:

Connects to a feature type Jira work item (HLT-2109)
Describes scope (api) and business intent (patient medication history)
"feat" can signal a new capability for automated release notes

This commit message links the change to the Jira feature work item and clearly describes the new endpoint's scope and business intent so reviewers can understand the purpose without searching other systems.

It documents data-privacy controls and the required authorization scope to demonstrate how personal health information access is protected for auditors. By referencing test work items the message makes it easy for QA and compliance teams to locate unit and integration test artifacts.

Possible customization: mention delivery artifacts like a Postman collection and CI job that signals that automated validation is in place and the change is verifiable.

See how the DevOps team at Philips links source code change to Jira work items to make completed work visible.

💡 How to verify?

3. Bug fix (Aerospace)

DEF-6789 fix(sensor): correct altitude data rounding in telemetry module

Fix floating-point precision issue causing 0.3-meter discrepancy in altitude
readings above 10,000 feet, violating mission planning accuracy requirements.

Safety Impact: MEDIUM
- Affects mission planning accuracy but not flight safety systems
- No impact to flight control or collision avoidance systems

Traceability:
- Requirement: REQ-TELEM-042 (Altitude Accuracy)
- Test cases: TC-ALT-001 through TC-ALT-016

✅ Why it works:

Links to a tracked defect (DEF-6789), preventing feature changes in a bug-fix branch
Contains precise technical correction
Uses subsystem tag (sensor) for subsystem traceability
Ensures commits/PRs that target a maintenance/hotfix workflow are actually linked to a Bug type work item

Defect traceability is a key compliance requirement in aerospace projects. This template includes an explicit safety impact assessment, aligning with DO-178C requirements. The Git commit message maintains traceability to requirements and could be customized to include test cases or configuration management details to support version control and change tracking.

Learn how EaglePicher, an aerospace contractor verifies code changes.

💡 Verify code changes in your Bitbucket repository

4. Documentation update (Defense)

ITAR-654 docs(crypto): update export control documentation for cryptographic modules

Add ITAR classification markings and export control guidance to all cryptographic
implementation documentation per DDTC compliance review findings.

Documentation Updates:
1. Added ITAR classification headers to 47 source code files
2. Updated README.md with export control warning
3. Added EAR99 exemption notes for publicly available encryption algorithms

Classification Details:
- Cryptographic implementations using AES-256, RSA-4096: ITAR Category XIII(b)(1)
- Key management protocols: ITAR Category XI(c)(10)

✅ Why it works:

Tracks documentation changes under their own Jira work item
Uses "docs" type for semantic clarity
Easy to filter during release packaging

Documentation is part of the release, so commits should reflect that.

This commit adds ITAR classification headers and export-control guidance to cryptographic implementation documentation to address DDTC compliance findings.

The commit explicitly lists classification details as ITAR Category XIII(b)(1); key management protocols as ITAR Category XI(c)(10) so reviewers, legal, and release engineers can make informed decisions.

💡 How to verify my devs comply with commit message rules?

5. Configuration change (Finance)

CFG-222 chore(config): update AML rule thresholds to align with 2025 policy

✅ Why it works:

"chore" identifies it’s not user-facing
Keeps audit trail for rule or policy updates
Connects directly to compliance work item (CFG-222)

Critical for auditors verifying compliance changes in financial infrastructure.

💡 How to verify?

6. Revert commit (Regulated industries)

REV-312 revert(auth): roll back OAuth2 token refresh change

Reverts commit a3f9c12 (HLT-2109 feat(auth): add OAuth2 login).
Reason: regression in token refresh flow causing session timeouts in production.

Impact: reverts to previous session management behavior pending root cause analysis.

✅ Why it works:

References both the revert work item and the original commit being rolled back
States the reason explicitly, which is required for audit trails in regulated environments
"revert" type keeps it filterable and excluded from changelogs automatically
Tracks the rollback as a controlled event, not an anonymous undo

In aerospace, medical, and finance environments, a revert without a traceable reason is a compliance gap. This template ensures every rollback is documented as a deliberate, reviewed decision.

💡 How to verify?

7. Merge commit template

MERGE-101 merge(dev → main): monthly integration merge

✅ Why it works:

Explicitly names source and target branches
Tracks merges as controlled events

For some branches, even merges are audit events. If conventions are enforced on all branches, skipping the merge commit verification is acceptable.

💡 How to verify?

8. Hotfix commit message example

HOT-909 hotfix(auth): correct token expiry causing login failures

✅ Why it works:

Identifies critical issue quickly (hotfix)
Links to production incident (HOT-909)

Hotfix messages should be short, structured, and traceable.

💡 How to verify?

9. Testing update commit message template

QA-876 test(ui): add regression suite for appointment booking flow

✅ Why it works:

Separates test-related commits
Enables analytics for test coverage

Teams can quantify test effort linked to Jira work items.

💡 How to verify?

10. Dependency update

DEP-940 chore(deps): bump log4j to 2.24.0 to fix security warning

✅ Why it works:

Dependencies have their own semantic tag (deps)
Explains the motivation clearly
Ties to a Jira dependency work item

Dependency updates are crucial to security, and it's a best practice to document them well.

💡 How to verify?

Enforcing Git commit message rules automatically

Creating your team's commit message conventions is one step. Making sure everyone follows it consistently is another.

Bitbucket Cloud has no built-in mechanism to reject a commit or block a pull request merge based on commit message content. There is no native hook, setting, or workflow that enforces this at push time. Enforcement requires an app-layer policy.

Better Commit Policy for Jira Cloud and Better Commit Policy Connector for Bitbucket Cloud enforce commit message standards in Bitbucket Cloud using a Policy-as-Code approach, where your commit policies are defined and maintained as YAML files.

For example, enforcing Git commit message template #3, the Bug fix commit message template for a hotfix branch, the commit policy would look like this:

commit:
  rejection-message: "Write a 10+ char long commit message, starting with a valid DEF Bug-type work item key! Watch for the correct cases."
  message:
    pattern: 'DEF-\d+\s+(\S\s*){10,}'
    work-item:
      jql: 'project = DEF and type = Bug'
      count: "1+"
      non-matching: "reject"

Meaning: the commit message has to contain at least one, valid, Bug type Jira work item key from the Defence (DEF) project, and be at least 10 characters long. Non-compliant commits are rejected.

Use this guide to configure and customize the rest of your commit policy and enforce the Git commit message templates.

Better Commit Policy for Jira and its Bitbucket Cloud Connector are trusted solutions for teams working in regulated industries.

Use them to:

Define commit policies (e.g. Jira work item key required, Conventional Commit pattern, Git 50/72 rule)
Enforce them at commit or merge time (as a local check or custom Bitbucket pull request rules)
Get instant feedback when something breaks the standard
Maintain full traceability between Jira work items and Git commits for easy audits
Understand the full enforcement model — see Commit policy enforcement in Bitbucket Cloud for how merge checks, branch rules, and PR validation work together

Start enforcing commit message templates in Bitbucket Cloud

Commit message conventions only work when every developer follows them on every commit. Better Commit Policy enforces the templates above automatically — no discipline required, no manual code review for formatting.

Teams in aerospace, medical devices, fintech, and enterprise SaaS use it to keep their Git history audit-ready without slowing down development.

Better Commit Policy for Jira Cloud

Also install Better Commit Policy Connector for Bitbucket Cloud (Free) to connect your Jira policies to Bitbucket.

Need help adapting the templates to your organization? Reach out to the Midori team for assistance.

Question or feedback on this post? Send us an email.

← Back to all posts