プル リクエストのマージ
When the desired number of reviewers have approved a pull request, you can merge the pull request if you have write (or admin) permission on the repository. If you've been touching the same code as someone else, you may have a merge conflict that you need to resolve locally. After you merge a pull request, you can revert the pull request to remove the merge commit from the repository.
プル リクエストのマージ
変更のマージは、プル リクエスト プロセスの最後の段階です。プル リクエストをマージするには、次の手順を実行します。
[マージ] ボタンを選択します。
（オプション）コミット メッセージに詳細を追加して更新します。注: メッセージのサイズは128KiBに制限されています。
Select a Merge strategy from the dropdown menu. For more information on merge strategies, see the Merge strategies section below.
(オプション) 同じリポジトリ内の 2 つのブランチをマージする場合、[ソース ブランチをクローズする] チェックボックスを選択して、リポジトリ ブランチの一覧からブランチを削除できます。
[マージ] ボタンを選択します。
また、Bitbucket は、マージしているブランチからのコミットのみで構成された他のプル リクエストも「マージ済み」としてマークします。たとえば、別のオープン プル リクエストがマージしているブランチに基づいていて追加のコミットがない場合は、もう一方のオープン プル リクエストも「マージ済み」とマークされます。
マージ チェックリスト
マージ チェックリストをセットアップする方法
You must be a repository administrator to add a merge checklist to a repository. For more details, see Suggest or require checks before a merge.
カスタムのマージ チェックを設定およびセットアップする方法
You must be a Workspace admin to configure and set up custom merge checks. For details, see Set up and use custom merge checks.
プル リクエストをマージしようとしたときに、マージ チェックリストが表示されることがあります。このチェックリストは、コードのマージ前に解決するように管理者が要求している項目の一覧です。 警告ラベルが表示されたチェックリスト項目は未解決です。
組織が Premium プランである場合、ワークスペース管理者はプル リクエストをマージする前に、マージ チェックが解決済みであることを要求できます。
このチェックリスト項目に警告ラベルが表示されている場合: | プル リクエストの状態 |
|---|---|
{#} 件以上の承認 | 承認数がその数を満たしていない |
最後のコミットで {#} 件以上のビルドに成功 | 最後のコミットで成功したビルドがその数を満たしていない |
最後のコミットですべてのビルドに成功 | 最後のコミットに失敗したビルドがある |
プル リクエスト タスクが解決済み | オープンなプルリクエスト タスクがある |
マージ チェックを表示する
プル リクエストの管理者またはレビュアーは、右側のサイドバーの上部にあるマージ チェック パネルでマージ チェック (必須または任意) を表示して、プル リクエストを承認する前に、完了したものと未完了のものを確認できます。
マージ戦略
Git merge strategies affect the way the Git history appears after merging a pull request. The type of strategy you choose to use depends on the workflow you've created for your workspace and how you use your repository.
マージ コミット — ソース ブランチのすべてのコミットを保持し、それらを宛先ブランチの一部にします。
このオプションは、コマンド ラインで「git merge --no-ff」と入力した場合と同じです。早送り — コミットをソース ブランチから宛先ブランチに移動させます (宛先に新しいコミットがない場合)。
このオプションは、コマンド ラインで「git merge --ff-only」と入力した場合と同じです。リベース、マージ
(rebase + merge --no-ff): ソース ブランチからターゲット ブランチにコミットし、受信コミットごとに新しい非マージ コミットを作成します。マージ コミットを作成し、ターゲット ブランチを更新します。この操作ではプル リクエスト ブランチが変更されません。リベース、早送り (
rebase + merge --ff-only): ソース ブランチからターゲット ブランチにコミットし、受信コミットごとに新しい非マージ コミットを作成します。結果のコミットでターゲット ブランチを早送りします。この操作ではプル リクエスト ブランチが変更されません。スカッシュ — ソース ブランチを宛先ブランチにマージする際にコミットを組み合わせます。
このオプションは、コマンド ラインで「git merge --squash」と入力した場合と同じです。
注: コマンド ラインにローカルで「git merge --squash」と入力すると、変更を Bitbucket にプッシュした後もプル リクエストは「open」状態のままになります。これは、コミット グラフを使用して変更が適用されたことを検出していて、"squash merge" を使用すると、プル リクエストがマージされたことを検出できず、正確な差分を表示できないためです。プル リクエストには 2 つのブランチ間で同じ変更が含まれるため、差分は表示されません。ただし、プル リクエストのコミット履歴を表示して個々のコミットを確認できます。スカッシュ、早送りのみ (
--squash --ff-only): ソース ブランチがターゲット ブランチよりも古い場合、マージ リクエストを却下します。そうではない場合、すべてのコミットをターゲット ブランチの新しい 1 つの非マージ コミットに結合します。
プル リクエストを元に戻すことはできませんが、プル リクエストによってマージされたコミットを必要に応じて戻すことはできます。Bitbucket はプル リクエストの巻き戻し処理を 2 ステップで実行します。1) Bitbucket はマージされたコミットを戻す 1 つのコミットを持つ、新しいブランチを作成します。2) Bitbucket はそのブランチおよびコミットに対する新しいプル リクエストを作成します。
マージされたプル リクエストを戻す
プル リクエストを戻すには、次の手順を実行します。
From the pull request, select Revert in the top right.
(オプション) [プル リクエストを元に戻す] ダイアログで、作成しようとしている新しいブランチのブランチ名にブランチ名を変更します。
Select Revert. Once you do, Bitbucket creates the new branch. Even if you cancel the pull request, the revert branch remains in the repository.
The Create a pull request page opens with the revert branch as the source. After you add your reviewers and make additional changes, select Create.
この内容はお役に立ちましたか?