4

職場では、git フローに基づく git ワークフローがあります。dev、release、master の 3 つのメイン ブランチがあります。

Dev は現在取り組んでいるもの、master は本番環境にあるもの、release はリリースを行って最後のバグ修正を行っているときです。リリースの準備が整うと、リリース ブランチがマスターにマージされ、本番環境にプッシュされます。

master で作成された修正プログラムはすべて dev (およびリリース ブランチ (現在実行中の場合)) にもプッシュされます。

問題は、リリース ブランチのコードが実際にマージ後に master にあるものであることをどのように保証するかということです。別の言い方をすれば、(マージ後) リリースとマスターの間に違いはないはずです。

リリース ブランチから master にマージするときも、競合に対処したくないため、競合はすべて自動的に処理する必要があります。

4

3 に答える 3

5

マスターにマージする際の競合を避けるために、「git merge --ours」を使用できます。これは、リリースの変更と競合するマスターの変更を無視しますが、複数の開発ストリームがある場合に問題が発生する可能性があります。たとえば、本番環境 (マスター) でコードを修正するサポートの問題がある場合、または複数のリリース ブランチがある場合です。

マージの競合は、ブランチを操作するときのパッケージ取引です。ワークフローを調整して、それらを分離して処理し、悪影響を最小限に抑えます。

これを説明するために、バグが修正された既存のバージョンが本番環境にあり、リリース ブランチを本番環境に移動する (マスターにマージする) 準備ができているシナリオを考えてみましょう。次のようになります。

master  -A---------E------G
          \   \   /      /
bug-fix    \   C-D      /
            \          /
release      B--*--*--F

この中で、 B と C は A から分岐し、 E はバグ修正時のコミット D のmasterへのマージ コミットであり、 G はリリース時のコミット F のmasterへのマージ コミットです。

G では、同じファイルがbug-fixreleaseの両方で変更されている場合、マージの競合が発生する可能性があります。を G で使用するとgit merge --ours、E で行った変更が失われる可能性があります。

マージは、master を分岐して release をマージし、この捨てられたブランチを master にリベースすることで処理できます。これは、プロセスが適切に管理されている場合 (たとえば、すべてのマージをマスターに行うように 1 人の担当者が指定されている場合) にのみ行う必要があります。

この時点で、G は F とまったく同じではなく、E のバグ修正コミットで導入された変更も含まれます。

masterと同様にbug-fixreleaseにマージすることも可能です。これにより、 F と G が再び同じになります。ただし、絶対にマージしないというベスト プラクティスがあります。これは、ブランチがダイアグラムに配置された順序で (上の方がより安定している)、常に下のブランチから上のブランチにマージする必要があることを意味します。これには 2 つの主な利点があります。1 つ目は、安定したコードが安定性の低いコードにマージされず、導入する機能に関連する変更のみが含まれているという意味でブランチが純粋なままであることです。たとえば、D がリリースにマージされた場合、リリースとともにテストする必要があります。そして release には、導入する機能の変更セットとバグ修正の変更セットの両方が含まれます。

これが問題にならないように、私は常により安定したブランチをチェックアウトし、安定性の低いブランチをそこにマージしてそこから移動します。

また、--oursチェックアウトされた--theirsブランチはマージされている他のブランチであることに注意してください。マージの方向を変更すると、それらが参照している変更がスワップされます。

于 2013-01-13T19:56:12.590 に答える
2

マージ後にリリースとマスターが異なることはありません。両方のブランチは同じコミットを指し、マージ コミットはブランチを結び付けます。したがって、それらはまったく同じです。

リリース ブランチの内容がマスター ブランチの内容になることを確認したい場合は、ours マージ戦略を使用します。これは master ブランチの変更を無視し、master ブランチの古い履歴をうまく上書きするだけです。だからあなたはするだろう

git checkout release
git pull --strategy=ours . master
于 2013-01-13T19:50:51.867 に答える
1

あなたが望むのは「私たちの」マージ戦略です。git mergeのマニュアルページで指摘されているように、マージの「our」側を常に使用し、「their」側のすべてを無視します。これは、一方が他方に完全に取って代わる場合に使用されることを明示的に示しています。

編集:「再帰的」戦略には「私たちの」戦略と「私たちの」オプションがあることに注意してください。戦略オプションはなく、前者の戦略が必要です。

于 2013-01-13T17:12:50.710 に答える