26

私の質問

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

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

これでプル リクエストが承認済みとしてクローズされることを期待していましたが、そうではありませんでした。

いくつかの背景情報

「プルリクエストでの作業」というビットバケットのドキュメントをたくさん読みましたが、これはまだ明確ではありません。

ブランチからのすべてのコミットが(経由で) ブランチnew_featureに適用されたことを確認でき、どのファイルが変更されたかを確認できますが、bitbucket のプル リクエスト インターフェイスで「マージ」を押すと、マスターに別のコミットがマージされます。これはファイルを変更しません（すべての変更は以前のによってすでに適用されています）が、それらすべてのコミット履歴をマスターに持ち込むだけで、私が望んでいたものではありません。mastergit merge --squashgit merge --squash

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

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

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

4

4 に答える 4

18

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

  1. 「マージ」ボタンをクリックします。Bitbucket は機能ブランチを目的のブランチにマージします。(Bitbucket の新しいバージョンでは、--no-ff 戦略と --squash 戦略のいずれかを選択できます。古いバージョンでは暗黙的に --no-ff が使用されます。)
  2. git コンソール コマンド (または他のインターフェイス) を使用して機能ブランチを目的のブランチにマージし、両方をオリジンにプッシュします。

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

2 番目のオプションを機能させるための鍵は、機能ブランチが目的のブランチにある必要があるということです。Bitbucket は、手動でマージされたプル リクエストを定期的にチェックし、見つかった場合、それらのプル リクエストを自動的にマージ済みとしてマークします。注: アトラシアンは、この動作を宣伝していません。私はこの主張を裏付ける公式文書を見つけることができませんでしたが、少なくとも 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は、機能ブランチが変更されるたびに、プル リクエストによって示されるコミットを自動的に更新します。ブランチをプッシュする順序によっては、コミット リストが空になる可能性があります。（これについては以下で詳しく説明します。）
  • プル リクエストがクローズされると、コミット履歴と差分情報は凍結されます。

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

変更はありません。

興味深いことに、この場合、差分はそのまま残ります。

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

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

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

于 2015-12-16T23:04:18.990 に答える
16

アップデート

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

詳細については、@BenAmos による回答を参照してください (そして賛成票を投じてください!) 。

元の回答

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

あなたは何も見逃していません。Bitbucket は、マージされたときにプル リクエストを自動的にクローズしません。

「拒否」オプションを選択して、手動でプル リクエストをクローズする必要があります。

ここに画像の説明を入力

于 2014-02-07T10:32:58.640 に答える