ブランチの自動マージ

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Bitbucket Data Center and Server can automatically merge changes to newer release branches, reducing the need for manual maintenance of branches. This page describes best practices for establishing a branching strategy conducive for automatic branch merging, and how to enable it for individual repositories or all repositories in a project.

自動マージのための条件

In order to use automatic branch merging, Bitbucket has to be able to determine the ordering of branches, and relies on semantic versioning of branch names. For example, Bitbucket will order these branch names like this: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Read more about the Branch ordering algorithm, including some examples of branch ordering, later on this page. Bitbucket expects that the 'development' branch, typically the default branch, is always ahead of any 'release' branches. The final merge in the automatic cascade will be to the 'development' branch.

次の条件も満たす必要があります。

  • ブランチ モデルが設定されていること。
  • "release" ブランチ タイプが有効化されているか、"production" ブランチが設定されていること。
  • "release" または "production" ブランチ タイプへのプル リクエストを使用してマージが作成されていること。
  • プル リクエストのターゲット ブランチよりも新しいブランチがあること。

参考情報

  • 自動マージはデフォルトでオフになっています。
  • コミット メッセージにはマージが自動的に行われたことが示されます。
  • 自動マージ用の監査ログ エントリがあります。
  • マージが成功または失敗すると通知が送信されます。

自動マージに失敗するとどうなりますか?

When an automatic merge fails, Bitbucket creates a new pull request for the failed merge, and the automatic merge operation stops. You should resolve the conflict locally before approving the new merge, which may start a new series of cascading merges. Note that a pull request that gets automatically opened when a merge fails won't trigger the continuation of the initial merge chain if resolved locally (which is the approach that we recommend).

自動マージが失敗する理由はいくつかあります。

  • マージの妨げになる競合が検出された
  • 自動マージでクローズする、同じソースとターゲットのを持つオープンなプル リクエストがすでに存在する

Example scenario of what happens when an automatic merge fails

For example, if you have multiple release branches, R1, R2, R3, and R4, they can all automatically merge into one another with automatic merging enabled. I.e., If you merge a pull request to R2, it will automatically merge R3 and R4 until you get to the development branch.

With automatic merging on, let's then say that there is a merge failure with R4. If you merge to R1, then Bitbucket merges to R2 and R3, but cannot merge to R4 because of the conflict. Bitbucket then opens a pull request from R3 to R4. The pull request is assigned to you because you attempted to perform the merge. Conflicts will need to be resolved and there are chances you may not even see that there was a pull request created.

There are two options available for how merging pull requests upstream from the conflict will behave:

  • Allowed to merge but only to the pull request opened for the merge conflict. This means that the next time a merge is attempted, there will be a warning stating that there is an open pull request downstream.
  • Blocked from merging until the pull request that was opened for the merge conflict is resolved. This means that any merging is blocked because of the open pull request downstream.

自動ブランチ マージを有効にする

1 つのプロジェクトのすべてのリポジトリで自動ブランチ マージを有効にし、個々のリポジトリではこの設定を継承するかオーバーライドするかを選択できます。 

1 つのプロジェクトのすべてのリポジトリで自動ブランチ マージを有効にする

1 つのプロジェクトのすべてのリポジトリで、自動ブランチ マージを含むブランチ モデルを継承またはオーバーライドできます。 

To enable automatic branch merging for all repositories in a project (requires project admin permission):

  1. Go to Project settings > Branches.
  2. Under Automatic merging, select the On status and then select Save.


1 つのリポジトリで自動ブランチ マージを有効にする

1 つのリポジトリで自動ブランチ マージを有効にする方法

  1. Go to Repository settings > Branches.
  2. Under Automatic merging, select the On status and then select Save.

ブランチの並べ替えアルゴリズム

Bitbucket is able to automatically merge changes to newer release branches, as long as Bitbucket can determine the ordering of those branches. Ordering is based on semantic versioning in the naming pattern for branches.

Bitbucket uses the following ordering algorithm to determine the branches in the merge chain:

  • ブランチは、カスケードを開始したブランチの名前 (マージのプル リクエストのターゲット) に基づいて選択および並べ替えられます。
  • ブランチ名は次の任意の文字を使用してトークンに分割されます: アンダースコア (_)、ハイフン (-)、プラス (+)、またはピリオド (.)。
  • プル リクエストのターゲットの名前に一致するブランチのみがマージ パスに追加されます。一致とは、最初の数値トークンよりも前のすべてのトークンが、ターゲット ブランチの名前の対応するトークンに等しいという意味です。
  • 指定されたトークンが数値の場合、ブランチは番号順に並べられます。数値トークンを ASCII トークンと比較した場合、数値が上位にランクされます (新しいバージョンであるとみなされます)。
  • 両方のトークンが数字ではない場合、シンプルな ASII 比較が使用されます。
  • 上記のアルゴリズムで 2 つのブランチ名が等しくなった場合、ブランチ名全体でシンプルな文字列比較が実行されます。
  • 30 マージの制限があります。 

ブランチの並べ替えの例

The table below provides examples of branch naming patterns that Bitbucket is able, and not able, to order correctly:

GOOD
  • release/1.0
  • release/1.1-rc1
  • release/1.1
  • release/1.2
  • release/2.0

Bitbucket tokenizes on the '.' and the '-' of '1.1-rc1' and is able to order these branch names correctly.

GOOD
  • release/bitbucket_1.1
  • release/bitbucket_1.2
  • release/bitbucket_2.0

Bitbucket tokenizes on the '.' and the '_' and orders the numeric parts of these branch names correctly.

BAD
  • release/1.0
  • release/bitbucket_1.1

Bitbucket tokenizes on the '.' and the '_' but cannot recognize that 'bitbucket_1.1' should follow '1.0'.

最終更新日 2021 年 8 月 31 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.