Require signed commits

Premium plan customers only

Requiring signed commits within a workspace is only available to administrators in organizations with a Bitbucket Cloud Premium plan

As the repository administrator, you can enable a setting that requires commits to have a verified signature in order to be successfully pushed.

As the repository administrator, next to the name of your repository in the left sidebar, select More actions (…), and then select Settings.
Select Repository details under General on the left sidebar.
Select the Advanced dropdown below the Repository details.
Select the Require all commits to have a verified signature checkbox under Signed commits.

Signed commits required	How it affects your team’s workflow
Enabled	Historical Commits: No changes are applied to historical commits. They remain unaffected after enforcement is turned on Pushing Commits: Every commit that gets pushed to the repository must be signed. If a commit is unsigned or the signature is invalid, the `git push` command will fail with an error, preventing the push. This is the primary point where enforcement occurs Merging Branches: Local branch merges can still be done without checks, and even if the commits being merged are unsigned, they can still be pushed. No signature validation will occur during or after the merge operation itself. The only check is during the actual `git push`, where commits in general must be signed Pull Requests (UI-based): Pull requests created through the UI will not be subject to commit signing enforcement for milestone 1+2, however we will have concept of system signs for M3 where commit, PR made through UI will be signed by BB.
Disabled	Historical Commits: No changes are applied to any historical commits Pushing Commits: Commits pushed to the repository do not require a signature. There are no checks or enforcement mechanisms in place, meaning unsigned commits can be pushed without errors Merging Branches: Local branch merges can be performed without any checks on commit signatures. Multiple commits being merged are allowed with no signature validation Pull Requests (UI-based): Pull requests created through the UI will not be subject to commit signing enforcement for milestone 1+2.

Signed commits required

How it affects your team’s workflow

Enabled

Historical Commits: No changes are applied to historical commits. They remain unaffected after enforcement is turned on
Pushing Commits: Every commit that gets pushed to the repository must be signed. If a commit is unsigned or the signature is invalid, the git push command will fail with an error, preventing the push. This is the primary point where enforcement occurs
Merging Branches: Local branch merges can still be done without checks, and even if the commits being merged are unsigned, they can still be pushed. No signature validation will occur during or after the merge operation itself. The only check is during the actual git push, where commits in general must be signed
Pull Requests (UI-based): Pull requests created through the UI will not be subject to commit signing enforcement for milestone 1+2, however we will have concept of system signs for M3 where commit, PR made through UI will be signed by BB.

Disabled

Historical Commits: No changes are applied to any historical commits
Pushing Commits: Commits pushed to the repository do not require a signature. There are no checks or enforcement mechanisms in place, meaning unsigned commits can be pushed without errors
Merging Branches: Local branch merges can be performed without any checks on commit signatures. Multiple commits being merged are allowed with no signature validation
Pull Requests (UI-based): Pull requests created through the UI will not be subject to commit signing enforcement for milestone 1+2.

Was this helpful?

It wasn't accurateIt wasn't clearIt wasn't relevant

Still need help?

The Atlassian Community is here for you.

Ask the Community