web-dev-qa-db-ja.com

バックマージとは

Git-flowスクリプトに関するビデオをいくつか見てきましたが、登場する用語の1つに「バックマージ」があります。ホットフィックスはマスターにマージされ、開発にバックマージされます。

バックマージは概念であり、ネイティブgitコマンドではないと想定しています。バックマージ操作を構成する正確なコマンドは何ですか？

gitgit-flow
9
mlhDev

通常、「バックマージ」という用語の使用はいくぶんarbitrary意的です。

それは、他と同様にマージを行うことを意味しますが、分岐規約の通常のフローと比較して「後方」の方向になります。次のように配置されたブランチを視覚化する場合

master    hotfix    release    dev    feature
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |
  |          |         |        |         |

その後、通常は「フロー」を右から左に変更します。機能はdevからマスターにリリースします。ただし、ホットフィックスはかなり左にありますが（マスターから作成されます）、まだ「右」にdevにマージする必要があるため、一部の人々はそれを後方マージまたはバックマージと説明しています。

私の意見では、これは用語の最も説得力のある使用ではありません。なぜなら、反対のマージ（devからホットフィックスブランチへ）が「前方マージ」であったことを暗示するために読むことができるからです-しかし実際はそうすべきではないできた。この場合、上記のように特定の方法でブランチを視覚化する場合、「後方」の方向は、変更の一般的な流れに関するものです。

この用語のより説得力のある使用法は、長寿命の機能ブランチがある場合です（これ自体は、gitflowを使用する可能性のあるアジャイルプロセスのアンチパターンのようなものですが、必要な場合もあります）。その場合は、devから長期間有効な機能を定期的に更新する必要があります。これにより、2つが大きく逸脱し、後でマージ競合の災害につながることはありません。 （そして、これは「不必要な」マージ、良い歴史を作るもの、そしてgit rerere...しかし、私は脱線します。）Thatは明らかに逆マージと呼ぶことができます。これは、反対に-機能をdevにマージする-ブランチモデルで通常の教科書のマージ使用です。

12
Mark Adelsberger

普通の2つのマージコマンドです。

git checkout master
git merge hotfix
git checkout develop
git merge hotfix

作業が完了すると、開発ブランチからmasterへのコミットの「通常の」フローを考えることができます。バックマージでは、コミットはhotfixinto開発ブランチから反対方向に流れます。

4
chepner

バックマージは現在の作業ブランチに修正プログラムの変更を追加します。

2つのブランチDevelopとMasterがあるとします
マスターに大きなバグを見つけました。 hotfixとしてMasterブランチ自体で修正しました。後でバグ修正の変更をcurrent working branchつまりDevelopブランチに追加する必要があります。あなたはback-mergeこのようにする必要があります

  1. git checkout Develop
  2. git mergeマスター
  3. git Push Origin Develop
3
Vrushali Raut