Better Commit Policy Connector for Bitbucket Cloud

Verify the changes (branches, tags, commits) and pull requests in Bitbucket against configurable rules

Get it free → Tutorial videos Documentation

Getting started with Better Commit Policy Connector for Bitbucket Cloud

How does it work?

Better Commit Policy Connector validates the changes committed to your Bitbucket repositories against the commit policy, a set of customizable 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, and pull requests, you ensure:

validated links between commits and Jira work items
validated links between pull requests 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

Check pull requests before merging

In addition to pushing commits, merging pull requests is another way to apply changes in Bitbucket-managed code. The app rigorously verifies pull requests, too.

Merging is allowed only if the pull request details satisfy the policy:

title
description
source branch
target branch
all commits in the pull request

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)
Supports complex infrastructures (N-to-M Jira-Bitbucket integrations)
Future-ready for all Bitbucket 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 Bitbucket 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 Git 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 Bitbucket apps and Git tools you already use

Better Commit Policy for Bitbucket extends the popular Bitbucket editor apps and all Git 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