web-dev-qa-db-ja.com

bitbucketのプルリクエストを手動で閉じる

私の質問

私はそのようなことをします：

git clone
git checkout -b new_feature
< work and commit >
git rebase master
< work and commit >
< finish working >
git rebase master
git Push Origin new_feature
< I create pull request via bitbucket's web interface >

変更をレビューしている誰かがやっています：

git pull
git checkout master
git merge --squash new_feature
git Push Origin master

これでプルリクエストが受け入れられて閉じられることを期待していましたが、閉じませんでした。

背景情報

私は多くのbitbucketのドキュメント「プルリクエストの操作」を読みましたが、これはまだはっきりしていません。

new_featureブランチからのすべてのコミットがmasterブランチに（git merge --squashを介して）適用されたことを確認でき、変更されたファイルを確認できますが、「マージ」を押すとbitbucketのプルリクエストインターフェイスでは、マージである別のコミットがマスターにあり、これはファイルを変更せず（すべての変更は以前のgit merge --squashによってすでに適用されています）、すべてのコミット履歴をマスターに持っています。私が欲しかったものではありません。

経由： https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests

ローカルシステムにリクエストを手動でプルする

プルリクエストを受け入れる前に、ローカルシステムで変更セットをテストするワークフローを使用することをお勧めします。これは任意のプルリクエストで実行できます。一般的なワークフローは次のとおりです。Bitbucketでプルリクエストを受信します。受信チェンジセットでローカルリポジトリを更新します。変更セットを調査またはテストします。変更セットに問題がなければ、それをローカルリポジトリにマージします。いくつかの競合を解決する必要がある場合があります。次に、ローカルリポジトリをBitbucketにプッシュします。 Bitbucketに戻ると、プルリクエストは[プルリクエスト]タブで承認済みとしてマークされています。変更リクエストが気に入らない場合は、変更をローカルで破棄し、Bitbucketでのプルリクエストを拒否します。アイデア？

gitbitbucketpull-request
23
user2046612

私が理解しているように、Bitbucketプルリクエストを「マージ済み」として閉じるには2つの方法があります。

  1. 「マージ」ボタンをクリックします。 Bitbucketは機能ブランチを宛先ブランチにマージします。 （Bitbucketの新しいバージョンでは、-no-ffと--squash戦略のどちらかを選択できます。古いバージョンでは暗黙的に--no-ffを使用します。）
  2. Git consoleコマンド（または他のインターフェース）を使用して機能ブランチを宛先ブランチにマージし、両方をOriginにプッシュします。

最初のオプションは間違いなく最も簡単で簡単ですが、特定の開発ワークフローではうまく機能しません。

2番目のオプションが機能するための鍵は、機能ブランチが宛先ブランチにある必要があることです。 Bitbucketは手動でマージされたプルリクエストを定期的にチェックし、見つかった場合、それらのプルリクエストを自動的にマージ済みとしてマークします。 注：Atlassianはこの動作をアドバタイズしません。私はこの主張を裏付ける公式の文書を見つけることができませんでしたが、少なくとも1人はそこにいます それが機能するのを見てきました 。

あなたが説明したワークフローに基づいて、変更をレビューしてプッシュした人が次のようなgit履歴を持っていると思います：

*   ddddddd (Origin/master, master) new feature, squashed
| * ccccccc (Origin/new_feature, new_feature) new feature part C
| * bbbbbbb new feature part B
| * aaaaaaa new feature part A
|/
o

この場合、Bitbucketにプルリクエストを自動的にクローズさせる最も簡単な方法は次のとおりです。

git branch --force new_feature ddddddd
git Push --force Origin new_feature

これは、リベースされた機能ブランチでも機能します。

警告！次の点に注意してください。

  • すべてのワークフローがこの種の強制プッシュを許可するわけではありません。
  • Bitbucket コミットを自動的に更新 機能ブランチが変更されるたびに、プルリクエストによって表示されます。ブランチをプッシュする順序によっては、これにより空のコミットリストが生成される可能性があります。 （これについては以下で詳しく説明します。）
  • プルリクエストが閉じられると、コミット履歴と差分情報が凍結されます。

機能ブランチをプッシュする前に宛先ブランチをOriginにプッシュすると、Bitbucketはまず、宛先ブランチにない新しくプッシュされた機能ブランチ上のコミットを探します。新しい機能ブランチは宛先ブランチの祖先であるため、結果は空のセットです。したがって、Bitbucketはプルリクエストの[コミット]タブからすべてのコミットを削除し、「変更はありません」と表示されます。次に、機能ブランチは宛先ブランチの履歴にあるため、Bitbucketはプル要求を閉じ、空のコミットタブを次のようにフリーズします。

There are no changes.

不思議なことに、この場合、差分はそのまま残ります。

上記のマージオプションがどれも機能しない場合、残りのオプションは次のとおりです。

  • プルリクエストを拒否します。
  • ワークフローをBitbucketがサポートしやすいものに変更することを検討してください。
  • フロート機能のリクエスト Bitbucket/Atlassianを使用。

git-branch および git-Push のドキュメントも参照してください。

15
Ben Amos

更新

2017年1月31日以降 機能が実装されました PRを手動で閉じることができないことに対処します。

詳細については（そして賛成投票してください！） @ BenAmosの回答 を参照してください。

元の回答

（歴史的な目的のために保管されています）

あなたは何も見逃していません。 Bitbucketは、マージされたプル要求を自動的に閉じません。

"Decline"オプションを選択して、手動でプルリクエストを閉じる必要があります。

enter image description here

12
Potherca

BitBucket Server 4.5.1は、プルリクエストでのリモートマージの分類方法（つまり、拒否またはマージ）を変更しました。

上記の@BenAmosの回答は適切に機能しますが、機能ブランチに強制的にプッシュする前に宛先ブランチにマージコミットをプッシュすると、BitBucketは自動的にプルリクエストを閉じて「拒否」として分類します。

ただし、マージコミットを宛先ブランチにプッシュする前に、機能ブランチにプッシュを強制すると、BitBucketはプルリクエストを自動的に閉じ、「マージ済み」として分類します。

Atlassianから：「次の場合、push後にプルリクエストが拒否されます。from-branchにコミットがなく、to-branchにもない、かつto-branchが同じPushで更新されていない」

参照： https://jira.atlassian.com/browse/BSERV-4219?src=confmacro&_ga=1.138319284.547646488.1457297841

1
McGeggles

おそらく、git merge --squashは完全にnewコミットを生成します。私たちの会社でもgit merge --squash機能ブランチをメインブランチにマージすると分岐しましたが、プルリクエストがこの方法でマージされたままであり、後でそれらを「拒否」するか、関連するリモートフィーチャーブランチを削除する必要があったため、あきらめました。

私たちが現在行っていることは、すべての機能ブランチのコミットを1つに押しつぶし、それをリモート機能ブランチに強制的にプッシュすることです。その後、マスターにマージする責任者は、ビットバケットのプルリクエストページで[マージ]をクリックするだけで、PRは「マージ済み」とマークされ、機能ブランチに導入されたすべての変更が1つのきちんとしたコミットに押しつぶされます。 。

0
Denis Malyshev