Scm Bitbucket
You set up scm bitbucket by creating a workspace, adding projects, and assigning team roles. Next, you add branch rules so every code change gets a review before merging. Most teams start by importing git repos and linking an identity provider for single sign-on. Still, broad admin roles often let developers bypass branch checks and push straight to main. Setting clear read and write roles early keeps your source code history clean and safe. How scm bitbucket roles and branch rules work The p
Bitbucket Pipelines Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up scm bitbucket by creating a workspace, adding projects, and assigning team roles. Next, you add branch rules so every code change gets a review before merging. Most teams start by importing git repos and linking an identity provider for single sign-on. Still, broad admin roles often let developers bypass branch checks and push straight to main. Setting clear read and write roles early keeps your source code history clean and safe.
How scm bitbucket roles and branch rules work
The platform groups your git repos inside workspaces and projects for easy team management. Admins grant users read, write, or admin roles at the project or repo level. A read role lets a user clone code and view pull requests. A write role lets a developer push branches and open new pull requests. An admin role lets a user change repo rules and add build keys.
Branch rules control how code moves from a feature branch into your main branch. You can require one or more peer reviews before anyone merges a pull request. You can also require passing build checks from your runner before a merge completes. These rules stop broken code from reaching your main branch during daily work.
Developers log in with SSH keys or personal tokens to push and pull code. Build servers use scoped keys to fetch code and run tests on every commit. Admins can also link the workspace to a central directory to manage user groups. When someone leaves the team, removing them from the directory revokes their repo role.
What native repo rules solve and what they miss
Native project roles and branch checks solve the core problem of code review governance. They make sure no single developer can alter the main branch without peer approval. They also give auditors a clear log of who approved and merged each pull request. For pure source code control, these built-in checks work well for most teams.
Still, source control is only the first step in a modern delivery workflow. Once a build runner or developer leaves the repo, git roles no longer apply. Build jobs and engineers still need to run commands against live servers and databases. Native repo roles decide who can merge code, not what live commands do in flight.
Bitbucket Pipelines Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Teams often store shared database passwords or server keys inside build variables. Anyone who can edit the build file in the repo can misuse those secrets. A rogue script or careless command can drop tables or read private customer data. Even if a pull request looks fine, live operational tasks still happen outside git. Protecting the repo does not stop bad queries or unsafe commands on live systems.
How to tighten your source control setup
Start by giving every developer the lowest role needed for their daily work. Put all repos inside projects so you do not have to set rules one by one. Turn on branch rules for main and release branches across the whole project. Require at least two peer reviews and a green build on every pull request.
Audit your SSH keys and repo tokens every month to remove old credentials. Replace long-lived personal tokens with short-lived build tokens wherever the tool allows it. Keep production secrets out of plain text files and review build script changes with care. Pair your code review rules with runtime controls when engineers touch live data.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What is the difference between a workspace and a project in scm bitbucket?
A workspace holds all repos, users, and billing settings for your whole company. A project sits inside the workspace to group related repos and share role rules.
How do I stop developers from pushing straight to the main branch?
Open the repo settings and add a branch rule for the main branch. Set direct push to none and require a pull request with peer approvals.
Should build runners use personal accounts to pull source code?
No, personal accounts break builds when that person leaves the team. Use a dedicated repo key with read-only rights so the runner only fetches code.