3

私たちの長年のgitブランチはMaster、UAT、Prodであり、新しい機能が最初にマスターにコミットされ、UATにプロモートされ（UATの準備ができたら）、Prodにプロモートされます（本番の準備ができたら）。現在、本番環境で修正プログラムを作成する機能が必要です。ProdブランチとリンクするHotfixブランチを作成することを計画しています。長時間実行されることに加えて、これらのブランチは、「非早送り」マージを使用してブランチを分離しておくという点で互いに分離されています（これにより、各ブランチでどのようなアクティビティが発生したかを簡単に確認できます。マスターからUATへのコードプロモーションなど）。

以下は、ホットフィックスが必要になった1つの通常の開発リリースのコミットのフローを示しています。開発は常に行われているため、マスターはコミットの大部分を占めています。UATとProdには、コードプロモーションを表すコミットのみがあります。ホットフィックスが必要な場合は、prodからhotfixにマージし、ホットフィックスブランチで変更を加え、ホットフィックス環境でテストしてから、prodにマージします。

hotfix ----------------------o-o----------   [1 commit for the merge prod->hotfix to get the latest state of prod into the hotfix environment, 1 commit of a bugfix to the hotfix environment]
prod   --------------------o-----o--------   [1 commit for the promotion uat-> prod to get the latest uat-tested code into prod, 1 commit for the promotion of the bugfix hotfix->prod]
uat    -----------------o-----------------   [1 commit for the promotion of master->uat of 4 master commits]
master --o---o---o---o----o-o--o---o-o--o-   [10 commits of new functionality]

ホットフィックスの後、ホットフィックスの変更は手動でマスターブランチに組み込まれることに注意してください。これは、ホットフィックスがリリースされた時間と現在の開発ラインの状態（数か月後になる可能性があります）によっては、コードがマスターとホットフィックスの間で大きく異なる可能性があり、ホットフィックスからマスターへの自動マージが意味をなさない場合があるためです。 。このため、UATからPRODへのマージ、PRODからHOTFIXへのマージ、およびHOTFIXからPRODへのマージでは、通常のgitマージを実行せず、代わりにgitmerge-sの戦略を使用します。あるブランチを別のブランチのようにするためのコマンド（具体的にはシミュレーション＃3を実行します）。

この戦略は、「アップストリームからダウンストリームへのすべての変更をマージし、ダウンストリームの状態を消去して、アップストリームからの変更に正確に置き換えてください」と言います。したがって、この戦略を使用してUATからPRODに移行する場合、基本的に「PRODをUATとまったく同じように見せます」と言います。これにより、本番環境に入るのは、UATにあったコードの状態とまったく同じになります。

このような変更を本番環境に導入するブランチが2つある場合（1つは通常のリリース用、もう1つはホットフィックス用）、git merge -s theirs戦略は、この種のマージ戦略を実行する正しい方法ですか？

ホットフィックスブランチがない場合は、マスターからuat、prodへの通常の（早送りではない）マージを実行し、必要がないため、git merge-stheirs戦略を使用しません。

4

2 に答える 2

1

3つのオプションがあります。

  • ブランチを新しいバージョンにリセットするだけです。（これはあなたの場合には選択肢がないようです。）
  • 「彼らの戦略」を使用して、gitに「古いバージョンを破棄して新しいバージョンに置き換える」ように指示します（ただし、gitはこれを簡単にサポートしていません）
  • または、-oursオプションを使用してPRODをmasterにマージすることにより、masterのホットフィックスの変更を「無効化」します。

PRODからmasterへの定期的なマージが可能な場合は、それを実行します。それ以外の場合は--oursとマージし、マスターで対応する変更を手動で行います。

于 2013-03-02T18:40:00.587 に答える
0

ブランチ戦略について考えてください。ある種類のプロジェクトに最適な戦略は、別のプロジェクトにとっては大きな負担になる可能性があります。

あなたの場合、通常の開発を行う1つの開発ブランチ（マスターなど）を提案し、リリースごとに個別のブランチ（リリースに基づく名前）を提案します。

リリースブランチはマスターから始まり、UATに入ります。このフェーズで見つかった問題には、マイナーな修正を適用できます。その後、本番環境に移行し、修正プログラムを直接適用できます。

あなたの場合、2つの異なるリリースのコミットをリンクする正当な理由は本当にありません。

于 2013-03-02T20:44:26.820 に答える