Better Commit Policy for Jira Cloud

Verify the changes committed to Git, Bitbucket, GitHub, GitLab against configurable rules

Try it free → Tutorial videos Documentation Buy

Getting started with Better Commit Policy for Jira Cloud

How does it work?

Better Commit Policy validates the changes committed to your Version Control System repositories against the commit policy, a set of configurable rules.

If the rules are not satisfied, the commits are rejected. Rejected commits must be corrected to comply with the rules and then re-committed.

Why should I use commit policies?

By enforcing rules on the commits, tags, branches, you ensure:

validated links between commits and Jira work items
traceable commit history
faster code reviews
continuous audit-readiness
... and more efficient development processes!

← Learn more by watching the intro video in the left.

Stay in control of every source code change

Rules can check every commit detail:

changed files (soon!)
commit message
commit author (soon!)
affected branches
affected tags (soon!)

Each rule:

can display resolution hints for developers when their commit is rejected

Supported Developer Platforms

Built for all major cloud-based Developer, DevOps and DevSecOps platforms.

Bitbucket
GitHub (soon!)
GitLab (soon!)
Azure DevOps (soon!)
AWS CodeCommit (soon!)

Ready for the Enterprise

Unlike free alternatives, Better Commit Policy is:

Well-documented
Commercially supported
Scalable (for enterprise-scale teams using Jira and Bitbucket)
Secure (SOC 2 Type II, vulnerability scanner, bug bounty program)
Future-ready for all Jira deployment types (Cloud, Data Center, Server)

Learn more about fast local Git commit verification (in 3 minutes)

Commit verification will not slow you down!

Fixing a wrong commit created hours ago is painful and costly. That's true.

Better Commit Policy works eagerly: it verifies commits before those are created. By preventing the creation of wrong commits, there is no need to fix anything later!

Better Commit Policy is the only commit checker app for Jira with this feature. Other apps verify commits only when those are sent to the server. And that's way too late!

Watch the video in the right and read how does local verification work? →

Works with your current tools

Your team members can use any standard-compliant VCS client (command-line, GUI tools, IDE integrations) on any Operating System.

Zero learning curve

After a couple of rejections, clean and precise commits become the new normal.

Keep Jira work items and development in sync

Ensure a reliable view of development activity in Jira by enforcing work item references in Bitbucket commits, pull requests, and branch names.

Benefits:

Reliable Development panel in the Work Item View
Reliable "Development" column in the Issue Navigator
Reliable development information on work item cards in Jira boards
Reliable development information on the Releases page
Jira automation rules triggered with the correct work item

Enforce well-formatted and traceable commit messages

Ensure every commit is traceable, properly formatted, and linked to the right Jira issue.

Commit message must match a pattern
- commit messages must start with a Jira work item key
- commit messages must be 10+ characters long
Commit message must contain work item keys from a JQL query
- commits must be linked to one or more valid Jira work items
- commits must be associated with exactly one story in the current sprint

Enforce consistent pull request titles

Accelerate code reviews and reduce your cycle time by ensuring pull requests are well-titled and linked to Jira work items.

PR title must match a pattern
- pull request title must start with a Jira work item key
- pull request title must be 10+ characters long
PR title must contain work item keys from a JQL query
- pull requests must be associated with a work item assigned to the author
- pull requests must reference bugs scheduled for the next release

Enforce informative pull request descriptions

Maintain PR description standards with custom checks for content, structure, and work item links.

PR description must match a pattern
- pull request description must not be left blank
- pull request description must include "Impact" and "How to test" sections
PR description must contain work item keys from a JQL query
- pull request description must not contain unresolved work items
- pull requests must be linked to at least one "Test" type work item

Enforce rules for source branches in pull requests

Streamline development with work item linked, well-formatted branch names.

PR source branch name must match a pattern
- source branch names must follow naming conventions (example: must start with feature/, bugfix/ or hotfix/)
- bugfix branch names must contain a work item from a specific project immediately after the slash (example: "bugfix/CAL-123-memory-leak")
PR source branch name must contain work item keys from a JQL query
- feature branch names must include a "Story" type work item from the current sprint (example: "feature/CAL-456-shared-calendars")
- bugfix type branch names must include a resolved "Bug" type work item assigned to the commit author (example: "bugfix/CAL-789-form-validation-crash")

Enforce rules for destination branches in pull requests

Standardize branch names with validated work item links for critical branches.

PR destination branch name must match a pattern
- deploy branch names must include the environment name (example: deploy/staging, deploy/production, deploy/qa and nothing else)
- release branch names must include a semantic version number (SemVer) (example: "release/7.1.0-beta")
PR destination branch name must contain work item keys from a JQL query
- deploy branches must be linked to a closed work item (example: deploy/CAL-123)
- hotfix branches must be linked to a high priority work item (example: hotfix/CAL-456-json-vulnerability)

Refine commit policy behavior with custom exceptions

Customize your commit policy to exclude certain users, ordinary commits, or merge commits for greater flexibility.

Ignore certain users
- allow selected users to be exempt from the commit policy (example: engineering leads can make changes that regular developers can't)
- skip commits created by your CI/CD system, dependency update bot, automations and such (example: GitHub Actions, Dependabot, Terraform)
Ignore ordinary commits
- skip ordinary commits if you only need to check merge commits
Ignore merge commits
- skip merge commits if you only need to check ordinary commits

Rigorous change control

Establish processes for compliance with ISO standards, IEC standards and industry regulations in:

defence
financial
avionics (success story)
automotive
medical
pharmaceutical
other safety-critical systems

Or, just make sure that every change to your code is introduced in a controlled and documented way!

End-to-end traceability

Accelerate requirements validation, compliance verification, impact analysis, coverage analysis and source code audits by bi-directionally linking Jira issues and source code changes:

requirements ⇔ code changes
epics ⇔ user stories ⇔ code changes
tasks / bugfixes ⇔ code changes
tests ⇔ code changes
change requests ⇔ sub-tasks ⇔ code changes
releases ⇔ issues ⇔ code changes

Faster code reviews & audits

Maintain development workflows for consistent repository, code & history.

By making small improvements (useful tips) in the way your team works, common questions like these will be automatically answered:

"Why was this changed?"
"Was it tested? In what environments?"
"Is this within the scope of the current release?"
"Who approved this merge?"
"Is there a programmatic test for this story?"

Why should I care about change control?

Integrated with the VCS tools you already use

Better Commit Policy for Jira extends all leading Version Control Systems and all VCS clients with commit verification features.

How does it help me work better?

Better Commit Policy success story (Aviation)

Helping the developer team comply with regulations and software requirements

"In the aviation industry, we need to be able to prove to authorities how exactly each aerospace system requirement is fulfilled and by what part of the source code. Better Commit Policy makes it easy to manage our Jira work items towards those requirements, proactively control what is committed to our source code repositories, and ultimately, to comply with regulations."

– Kalen Brown, Associate Electrical and Computer Engineer

Read the story →

Better Commit Policy success story (Medical)

How developers of safety-critical systems at Philips manage source code changes

"Before using commit policies, our developers’ behavior was like in the wild west. We couldn’t match source code changes with Jira issues, it was almost impossible to understand what work has really been done, we wasted time. The Better Commit Policy app helps us maintain a manageable development process by enforcing some configurable rules in a friendly, but strict way."

– Yakov Yukhnovetsky, DevOps Engineer