Lesstep
Bitbucket Cloud・Data Center・プルリクの差分・2026年11月2日に確認

Bitbucket のプルリクに、宛先ブランチへもう入った変更が出る

Bitbucket のプルリクは、元のブランチを「今の宛先ブランチ」と比べてはいません。比べる相手はマージベース、つまり2つのブランチが共有している最後のコミットです（git の3点の diff）。スカッシュマージなど別の道で宛先に入った変更は、この共有の履歴に入らないので、もう一度出てきます。Atlassian はこれを仕様どおりとしていて、Cloud 向けと Data Center 向けに1本ずつ記事があります。マージして変わるのは新しい分だけです。下に、本当に新しいファイルの見分け方と、プルリクにそれだけを出す直し方を書きます。

Bitbucket が比べているもの

プルリクと同じファイルの一覧を手元で出すには：

git fetch
git diff --stat origin/main...origin/feature

マージで本当に何が変わるかは、git にブランチを動かさずにマージを作らせ、宛先と比べると分かります（git 2.38 以降）：

git diff --stat origin/main $(git merge-tree --write-tree origin/main origin/feature | head -1)

1つ目のほうが多くのファイルを出すなら、その差の分は宛先にもう入っています。

前にスカッシュマージしたブランチ

Atlassian の Cloud の記事の例がこれです。qa や develop のように使い続けるブランチを、main へスカッシュマージします。スカッシュマージは main に新しいコミットを1つ足すだけで、ブランチのコミットをマージ済みとは記録しません。そのためマージベースは元の位置に残り、同じブランチからの次のプルリクに古い変更がまた出ます。11月2日の試しでは、5つのファイルをスカッシュマージしてから1つ足すと、3点の diff は6ファイル、本当のマージは1ファイルでした。

そのブランチを一度直すには、宛先をブランチにマージして push します：

git switch qa
git merge origin/main
git push

これで宛先の最新のコミットがマージベースになり、プルリクには新しいコミットの分だけが出ます（同じ試しで6ファイルが1ファイルに）。スカッシュしたファイルをその後ブランチでまた変えていると、このマージはそのファイルで止まります（試しでは CONFLICT (add/add)）。そのファイルはブランチの側を残します。このマージの間は git checkout --ours <ファイル> でブランチの側になります。続けて git add と git commit。

根本から避けるなら、使い続けるブランチはスカッシュマージしないことです。そうしたブランチはマージコミットでマージし、スカッシュマージは、マージした後に閉じる短いブランチに使います（Bitbucket のマージ方法）。

スカッシュマージしたブランチの上に作ったブランチ

feature-b を feature-a から作り、feature-a を main へスカッシュマージしたら、feature-b のプルリクに feature-a の変更まで出るようになった場合です。宛先を main に変えても直りません。マージベースが古いままだからです。feature-b 自身のコミットだけを main の上へ移します：

git switch feature-b
git rebase --onto origin/main {feature-a の最後のコミット} feature-b
git push --force-with-lease

feature-a の最後のコミットは、マージ済みのプルリクの Commits タブのいちばん新しいコミットです。試しでは、プルリクの差分が2ファイルから1ファイルになりました。リベースはブランチを書き換えるので、push は強制になります。ブランチの権限で履歴の書き換えを禁じていると、Bitbucket は受け付けません（「pre-receive hook declined」）。

並行するリリースブランチ

長く使う2つのブランチを互いに何度もマージしていると、マージベースが2つ以上になることがあります。たとえば2本のリリースブランチを、それぞれ main と別のブランチの両方へマージした場合です。git はそのうち1つを選ぶので、宛先にもう入った変更が出ることがあります。Atlassian の Data Center の記事がこの流れをたどっていて、手元の git diff も同じ結果なら Bitbucket の不具合ではない、としています。

git merge-base --all origin/main origin/release

2行以上出たら、この場合です。Atlassian は、リリースブランチを一度に1本にする進め方を勧めています。上のように宛先を元のブランチへマージしても、マージベースは1つに戻ります。

IntelliJ IDEA で Bitbucket のプルリクを

Pull Request Inbox for Bitbucket は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。プルリクのファイルを IDE の差分ビューアーに、Bitbucket のページと同じくマージベースから比べて出します（Cloud・Data Center）。プルリクのブランチをチェックアウトでき（Checkout）、上のコマンドはそこで打てます。push の後は、前回のレビューから変わったところを出します。読むのは無料、プルリクの作成・承認・マージは Pro（月 US$1.50・30日間の試用つき）です。画面は日本語です。

JetBrains Marketplace で入れる

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

ほかに：Bitbucket のマージ方法 · 前回のレビューからの変更だけを見る · プルリクの宛先ブランチを変える · English