Bitbucket Cloud・Data Center・プルリクのマージ・2026年10月28日

Bitbucket のマージ方法：マージコミット・スカッシュ・早送り・リベース

Bitbucket でプルリクエストをマージする時はマージ方法（merge strategy）を選び、それでターゲット ブランチの履歴の形が決まります。Cloud と Data Center の一覧はほぼ同じで、違うのは方法1つ・設定の場所・API の名前です。Atlassian の Merge a pull request（Cloud）と Pull request merge strategies（Data Center）から。

マージ方法の一覧

• Merge commit（--no-ff）：Cloud merge_commit・Data Center no-ff
• Fast-forward（要ればマージコミット）（--ff）：Cloud には無い・Data Center ff
• Fast-forward only（--ff-only）：Cloud fast_forward・Data Center ff-only
• Rebase, merge（rebase ＋ merge --no-ff）：Cloud rebase_merge・Data Center rebase-no-ff
• Rebase, fast-forward（rebase ＋ merge --ff-only）：Cloud rebase_fast_forward・Data Center rebase-ff-only
• Squash（--squash）：Cloud squash・Data Center squash
• Squash, fast-forward only（--squash --ff-only）：Cloud squash_fast_forward・Data Center squash-ff-only

• Merge commit は元ブランチのコミットをすべて残してマージコミットを足します。元ブランチが最新でも足します。Data Center の既定です。
• Fast-forward only と Squash, fast-forward only は、元ブランチがターゲットより古いとマージを断ります。Data Center のただの Fast-forward は、その時マージコミットを作ります。
• 2つのリベースは、元ブランチの各コミットの写しをターゲットの上に積みます。プルリクのブランチ自体は変わらない、と Atlassian は書いています。
• Squash は変更をまとめた新しいコミットを1つ、ターゲットに作ります。

既定と、許す方法を決める場所

• Cloud：リポジトリの設定 ＞ Merge strategies で、リポジトリの管理者が Default merge strategy（マージの画面で最初から選ばれている方法）を選びます。プロジェクトの管理者はプロジェクトの設定 ＞ Workflow ＞ Merge strategies で決められ、プロジェクトに足したリポジトリは、プロジェクトの設定を引き継ぐようにして初めてそれに従います（Set up a merge strategy for a project）。
• Data Center：プロジェクトかリポジトリの設定 ＞ Merge strategies で、方法ごとのスイッチと Set as default。リポジトリは Use custom settings にしない限りプロジェクトの設定を引き継ぎます。Bitbucket 8.10 からはプロジェクトの管理者が Don't allow changes to merge strategies を選べ、その時リポジトリの独自の設定は消えてプロジェクトの設定になります。
• Data Center では、そこで有効にした方法だけがマージの時に選べます。Cloud では、API がプルリクごとにターゲット ブランチで使える方法を返します。

コミットメッセージ

• Cloud：Merge pull request の画面で、マージの前に Commit message へ詳しいことを書き足せます。長さは 128 KiB までです（Merge a pull request）。API のマージでは message で渡します。
• Data Center：プロジェクトかリポジトリのマージ方法の設定で決めるコミットメッセージのテンプレートが、マージの画面のメッセージの題（必須）と本文を埋めます。プルリクの題や番号、ブランチ名、承認した人などの変数が使えて、マージの前に書き換えられます。マージやスカッシュの時にコミットの要約をいくつ入れるかは別の設定で、0 なら入りません（Pull request merge strategies）。
• どの方法で使われるか：メッセージは、マージで新しくできるコミット（マージコミットか、スカッシュの1つのコミット）に付きます。Fast-forward only は新しいコミットを作らず（ターゲット ブランチが元ブランチの最後のコミットへ進むだけ）、Rebase, fast-forward は元のコミットの写しをそれぞれのメッセージのまま上に積むので、どちらもメッセージを付けるコミットがありません。Data Center の Fast-forward は、マージコミットを作る必要がある時だけ使います。

よくあるつまずき

• 手元でスカッシュしたらプルリクが開いたまま：手元で git merge --squash してプッシュすると、Bitbucket Cloud はコミットのつながりからマージされたと分からず、差分の無いプルリクが開いたまま残ります。Bitbucket の Squash でマージします。
• Fast-forward only に断られる：元ブランチがターゲットより古くなっています。ターゲットをリベースかマージで取り込んでプッシュするか、マージコミットを作る方法を選びます。
• リベースの落とし穴（Data Center）：リベースでマージしたブランチの上に作ったブランチを、さらにリベースでマージすると、中身の無い重複したコミットが入ることがあります。Bitbucket がリベースしたブランチを手元で git pull すると、古いコミットとリベース後の写しがマージされることがあります。同時に入った変更とぶつかったリベースは transactional failure になるので、少し待って読み直し、もう一度マージします。
• 衝突：どの方法でも、Bitbucket はリポジトリを元のままにします。手元で衝突を解いてプッシュしてから、もう一度マージします。
• API で：Cloud のマージは merge_strategy を受け取り、API の説明では既定が merge_commit なので、使いたい方法を送ります。プルリクの destination.branch に merge_strategies と default_merge_strategy があります。Data Center は strategyId を受け取り、有効な方法はリポジトリの settings/pull-requests の mergeConfig にあります。
• マージできないトークン（Data Center）：マージはコミットを作るので、プロジェクトとリポジトリのアクセストークンではマージできず、個人のトークンは公開の報告で Repository admin が要りました（製品ページの API トークンの段に詳しく）。

IntelliJ IDEA でのマージ方法

Pull Request Inbox for Bitbucket は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。Bitbucket Cloud と Bitbucket Data Center のプルリクエストを IDE のツールウィンドウに並べます。マージの画面にはターゲット ブランチで許された方法だけが出て、リポジトリの既定が最初から選ばれ、コミットメッセージと元ブランチを閉じるかも選べます。1.0.52 からはメッセージの欄が Web と同じく複数行になり、スカッシュのコミットにも1行目の下へ本文を書けます。Fast-forward only と Rebase, fast-forward では欄が止まり、理由を出します。まだ残っているマージチェックも文で出します。レビューの受け箱とマージチェックは無料、承認・コメント・マージは Pro（30日間の無料試用つき）です。画面は日本語です。

JetBrains Marketplace で入れる

Bitbucket は Atlassian Pty Ltd の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは Atlassian・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：マージの衝突 · Bitbucket の自動マージ · Bitbucket のマージチェック · modify a pull request based on out-of-date information（Data Center） · Bitbucket の既定のレビュアー · IntelliJ IDEA で使える Bitbucket のプルリクエストのプラグインの比較 · English