Skip to content

Other platforms — Azure DevOps and Bitbucket

Do not guess. This file lists documented, verifiable capabilities only. When auditing ADO or Bitbucket, prefer official docs and UI screenshots over invented CLI commands.

Use diagnostic-prompt.md Phases 0–2 and 5–7; replace Phase 3–4 GitHub commands with the UI paths below.

Azure DevOps (Azure Repos)

Official docs: Branch policies

What ADO supports (documented)

Control ADO mechanism Notes
Require pull request Branch policy: Require a minimum number of reviewers (≥1, no bypass) Effectively blocks casual direct push when combined with permissions
Block force push Branch security + policies; Bypass policies when pushing restricted Verify per branch permissions
Limit merge types Branch policy: Limit merge types Documented options include basic merge (no FF), squash, rebase — confirm allowed set in UI
Build validation Branch policy: Build validation Pipeline must succeed before merge
Status checks Branch policy: Status checks External or pipeline statuses
Linear history Not a single GitHub-style toggle Achieved by disallowing merge commits via Limit merge types (allow rebase/squash only) — verify in project
Branch scope Policies on branch name patterns (e.g. main, release/*) Project-level defaults possible
Large file push block No direct equivalent to GitHub push rulesets documented here Use Git LFS, pipeline checks, or server hooks — verify org policy separately

UI audit path (single repo)

  1. Repos → Branches → main (⋯) → Branch policies
  2. Capture: reviewers, merge types, build validation, status checks
  3. Project settings → Repositories → Policies (if project-wide defaults exist)
  4. Permissions on main: who can push, bypass policies

Org / project vs repo

  • Branch policies are typically defined per branch pattern in a project; multiple repos in a project inherit project structure but policies are configured per repo branch in Azure DevOps Git.
  • Ask user whether policies should be set at project template level or per-repo branch — ADO UI varies by organisation setup.

Local dev (ADO)

  • Same git practices as GitHub: feature branches, PRs, no direct commits to protected branch
  • Clone URL and auth via PAT or Azure identity
  • Large files: Git LFS with Azure Repos — verify LFS enabled for org

What we do not claim without evidence

  • Native 3 MB file push rejection on Azure Repos (unlike GitHub push rulesets)
  • A single az devops command that dumps all branch policies for all repos — partial coverage via REST API; ask user for admin access or export

Bitbucket (Cloud)

Official docs: Suggest or require checks before a merge, Use pull requests for code review

What Bitbucket supports (documented)

Control Bitbucket mechanism Notes
Require pull request Branch permissions: prevent direct pushes; require PR Workspace / project / repo level
Block force push Branch permissions Configure on branch pattern
Merge strategies Repository settings → Merge strategies Options documented: merge commit, squash, fast-forward, squash fast-forward, rebase — default strategy is repo-configurable
Require passing builds Merge checks / pipeline requirements Bitbucket Pipelines integration
Branch restrictions Branch restrictions on patterns Read/write access control
Large files Git LFS supported No GitHub-style push ruleset documented in Atlassian docs reviewed for this skill

UI audit path (single repo)

  1. Repository settings → Branch permissions (or Branch restrictions)
  2. Repository settings → Merge strategies — which strategies enabled
  3. Repository settings → Pull Requests — merge checks, default reviewers
  4. Workspace-level defaults: Workspace settings → Branch restrictions (if used)

Workspace vs repo

Ask user: apply at workspace, project, or repository level. Bitbucket Cloud allows hierarchy; exact inheritance depends on workspace configuration.

Local dev (Bitbucket)

  • Standard git feature-branch workflow
  • git push to PR branch; merge via UI with repo-allowed strategy
  • Large files: enable Git LFS in repo settings

What we do not claim without evidence

  • Fine-grained "rebase-only" ruleset equivalent to GitHub's merge-method rule on all Bitbucket tiers — merge strategy control is primarily via enabled merge strategies at repo level
  • Org-wide scan CLI — use Bitbucket REST API with user-provided credentials or manual workspace repo list

Cross-platform local dev (all hosts)

Practice Rationale
Use git-hygiene skill before coding Clean branches from current default
One PR per feature branch Reviewable, revertible units
Avoid squash if policy is rebase-only Prevents ghost branches on GitHub
Store binaries externally Passes large-file rules; shrinks clone
git filter-repo for accidental large commits Rewrite feature branch before merge
Pre-commit hooks optional Local fast feedback; server rules authoritative

When platform is unknown

Ask the user which host hosts the remote. Inspect:

git remote -v
  • github.com → GitHub path
  • dev.azure.com / visualstudio.com → Azure DevOps
  • bitbucket.org → Bitbucket
  • Self-hosted GitLab / Gitea → out of scope for this skill; suggest separate skill or manual audit