技術資料

GitHubを使っていた人がBitbucket Cloudを使い始める場合、Gitのコマンドを覚え直す必要はほとんどありません。clone、branch、commit、push、Pull Request、review、mergeという基本の流れは共通しています。

一方で、Bitbucket CloudではWorkspace・Project・Repositoryの関係や、Branch restrictionsの設定を確認する必要があります。今回はGitHubとの違いを中心に、練習用Repositoryの作成からPull Request、ブランチの制限までを整理します。

この記事はBitbucket Cloudを対象にしています。Jiraとの連携やBitbucket Pipelinesの設定は、ここでは概要に留めます。

GitHubとBitbucketでGitの基本操作は共通

GitHubとBitbucket Cloudは、どちらもGitリポジトリをホスティングするサービスです。そのため、ローカルで行う次の操作は基本的に同じです。

clone
branch
commit
push
Pull Request
review
merge

画面上の名称には違いがありますが、GitHubの経験があれば、操作の流れは理解しやすいと思います。

Bitbucket Cloud	GitHubで近い画面・機能
Source	Code
Pull requests	Pull requests
Pipelines	Actions
Branch permissions / restrictions	Branch protection rulesなど

これは画面を探すときの目安です。機能が完全に一対一で対応しているわけではありません。特にブランチの保護設定は、Bitbucketでは権限とmerge前の条件を分けて考える必要があります。

Workspace・Project・Repositoryの関係

Bitbucket Cloudでは、Workspaceの中にRepositoryを作成します。複数のRepositoryをProjectにまとめることもできます。

Workspace
├─ Repository
├─ Project
│  ├─ Repository
│  └─ Repository
└─ Repository

ProjectはRepositoryを整理するための任意のまとまりです。必ずProjectを作ってからRepositoryを作成しなければならないわけではありません。複数のRepositoryをチームや製品ごとにまとめたいときに利用できます。

GitHubでは、個人アカウントまたはOrganizationの下にRepositoryを置く形が基本です。Bitbucket CloudではWorkspaceがその管理単位にあたり、必要に応じてProjectでRepositoryをグループ化します。Projectの作成にはWorkspace管理者の権限が必要です。

Repositoryを作成してローカルへcloneする

練習する場合は、Bitbucket CloudでWorkspaceを選び、公開して問題のないサンプル用Repositoryを作成します。Projectに所属させる場合は、既存のProjectを選ぶか、Workspace管理者に作成を依頼します。

Repositoryを開き、Cloneから表示されるURLをコピーして、ローカルへcloneします。

git clone https://<bitbucket-username>@bitbucket.org/<workspace>/<repository>.git
cd <repository>
git switch -c feature/update-readme

HTTPSを使う場合は、Git Credential Managerで認証するか、BitbucketのAPI tokenをパスワードとして入力します。API tokenにはRepositoryを読むための権限が必要です。pushも行う場合は書き込み権限も必要になります。tokenをコマンドやGitのremote URLへ直接書くと履歴や設定に残る可能性があるため、認証プロンプトやSSHを利用してください。

BitbucketのApp passwordsは新規作成が終了しており、既存のものも2026年6月9日に無効化されています。古い手順にあるApp passwordではなく、現在利用できるAPI tokenやSSH認証を使います。

ファイルを変更したら、GitHubと同じようにcommitしてpushします。

git add README.md
git commit -m "Update README"
git push -u origin feature/update-readme

実際に使うときは、commit前にgit statusで変更対象を確認します。clone URL、認証方式、Repository名は、Bitbucketの画面に表示される値に合わせてください。

Pull Requestで変更をレビューする

branchをpushしたら、RepositoryのCreateメニューからPull requestを作成します。作成画面では、変更元のRepositoryとbranch（Source）、取り込み先のRepositoryとbranch（Destination）、タイトル、説明、Reviewersを指定します。

Pull Requestを作成した後は、変更差分とcommitを確認し、必要に応じてファイルや行単位のコメントを追加します。レビューが済んだらApproveし、条件が揃った段階でmergeします。作成時にClose branchを選ぶと、merge後に作業branchを閉じる設定もできます。

feature/update-readme
        ↓ Pull Request
       main

merge後はローカルのmainを更新し、不要になったbranchを削除します。

git switch main
git pull
git branch -d feature/update-readme

画面の見た目や項目名は変更される場合がありますが、変更元と取り込み先を指定し、差分をレビューしてmergeする考え方はGitHubと同じです。

Branch restrictionsで重要なbranchを守る

Repository settingsのWorkflowにあるBranch restrictionsでは、特定のbranchやbranch名のパターンに対して、書き込みやPull Request経由のmergeを制限できます。例えばmainへの直接pushを制限し、Pull Requestを経由して変更を取り込む運用にできます。

主に確認する設定は次のとおりです。

• Write access: 対象branchへ直接書き込めるユーザーやグループを制限する
• Merge access via pull requests: Pull Request経由で対象branchへmergeできるユーザーやグループを制限する
• Branch history rewrite / deletion: 履歴の書き換えやbranch削除を許可する範囲を確認する

「誰がbranchへ書き込めるか」と「誰がPull Requestをmergeできるか」は別の権限です。例えばmainへの直接pushを許す担当者を少数にし、Pull Requestのmergeはレビュー担当者に許可する、といった設定ができます。設定する人にはRepositoryの管理権限が必要になる場合があるため、画面に項目がないときはWorkspaceやRepositoryの管理者へ確認してください。

GitHubのBranch protection rulesと目的は近いものの、設定名や制御方法は異なります。GitHubでは承認済みレビューやStatus checksなどの条件をbranch保護ルールに設定できます。BitbucketではBranch permissionsでアクセス権を決め、Merge checksでmerge前に満たしたい条件を設定します。

FreeプランではMerge checksの強制に注意する

Merge checksでは、承認数、成功したbuild、未解決のPull Request taskがないことなどをmerge前の条件として設定できます。Pipelinesや外部のbuild結果を条件にすることもできます。

ただし、Bitbucket CloudのFreeプランでは、条件が満たされないときに警告は表示されても、merge自体を止められません。条件未達のmergeを強制的に止めるにはPremiumの設定が必要です。GitHubのRequired status checksやレビュー必須と同じ強制力があると考えず、利用プランと設定画面を確認してください。

また、Merge checksを設定することと、成功するCIを用意することは別です。Bitbucket Pipelinesや連携済みのbuild toolから結果が報告されていなければ、成功build数を条件にしても期待した確認にはなりません。CIの設定方法は、別途Bitbucket Pipelinesの記事で扱います。

チームで使い始める前に確認すること

Bitbucket Cloudの機能や設定は、Workspaceの権限、Repositoryの設定、契約プランによって異なります。チームのRepositoryへ参加したときは、Gitの操作を始める前に次の点を確認しておくと安心です。

• Workspace内でProjectをどう使い、Repositoryをどこに置くか
• branch名やcommit messageに関する命名規則
• Pull Requestの作成先、Reviewer、Approveのルール
• mainなどの保護対象branchと、直接pushできる範囲
• mergeに必要なレビュー、CI結果、未解決taskの扱い
• Jira連携やBitbucket Pipelinesが設定されているか

GitHubでの経験を活かせる部分は多いですが、Repositoryの権限やmerge条件はチームごとに決められています。画面の機能名だけで判断せず、対象branchと実際の権限を確認してから作業を進めましょう。

まとめ

GitHub経験者であれば、Bitbucket Cloudのclone、branch、commit、push、Pull Request、review、mergeは、これまでのGitの知識を使って進められます。

• WorkspaceがRepositoryを管理し、Projectは複数Repositoryを整理する単位として使える
• Pull RequestではSourceとDestinationを確認し、差分とcommitをレビューする
• Branch restrictionsで書き込み権限とPull Request経由のmerge権限を設定する
• FreeプランのMerge checksは警告に留まり、mergeを強制停止するにはPremiumが必要
• HTTPS認証にはAPI tokenなどを使い、tokenをURLへ直接残さない

まずはWorkspaceとRepositoryの構成を把握し、チームで決めているbranch保護やレビューのルールを確認すると、GitHubとの違いに戸惑いにくくなります。

参考資料

• Atlassian Support: Join or create and manage workspaces in Bitbucket Cloud
• Atlassian Support: Create a project
• Atlassian Support: Clone a repository
• Atlassian Support: Using API tokens
• Atlassian Support: Revoke an App password
• Atlassian Support: Create a pull request for review
• Atlassian Support: Review a pull request
• Atlassian Support: Use branch permissions
• Atlassian Support: Suggest or require checks before a merge
• GitHub Docs: About protected branches
• GitHub入門：Codexで変更を依頼してPull Requestを作成する
• GitHubユーザー向けJira入門：課題タイプ・親子関係・JQLの基本