私の質問
私はそのようなことをします:
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 のプル リクエスト インターフェイスで「マージ」を押すと、マスターに別のコミットがマージされます。これはファイルを変更しません(すべての変更は以前のによってすでに適用されています)が、それらすべてのコミット履歴をマスターに持ち込むだけで、私が望んでいたものではありません。master
git merge --squash
git merge --squash
経由: https://confluence.atlassian.com/display/BITBUCKET/Working+with+pull+requests
リクエストをローカル システムに手動でプルする
プル リクエストを受け入れる前に、ローカル システムで変更セットをテストするワークフローを使用することをお勧めします。これは、任意のプル リクエストで実行できます。一般的なワークフローは次のとおりです: Bitbucket でプル リクエストを受信します。着信変更セットでローカル リポジトリを更新します。変更セットを調査および/またはテストします。変更セットが適切であれば、それをローカル リポジトリにマージします。いくつかの競合を解決する必要がある場合があります。次に、ローカル リポジトリを Bitbucket にプッシュします。Bitbucket に戻ると、プル リクエストは [プル リクエスト] タブで承認済みとしてマークされます。変更リクエストが気に入らない場合は、変更をローカルで破棄し、Bitbucket でプル リクエストを拒否します。アイデア?