マスターにマージする際の競合を避けるために、「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-fixとreleaseの両方で変更されている場合、マージの競合が発生する可能性があります。を G で使用するとgit merge --ours
、E で行った変更が失われる可能性があります。
マージは、master を分岐して release をマージし、この捨てられたブランチを master にリベースすることで処理できます。これは、プロセスが適切に管理されている場合 (たとえば、すべてのマージをマスターに行うように 1 人の担当者が指定されている場合) にのみ行う必要があります。
この時点で、G は F とまったく同じではなく、E のバグ修正コミットで導入された変更も含まれます。
masterと同様にbug-fixをreleaseにマージすることも可能です。これにより、 F と G が再び同じになります。ただし、絶対にマージしないというベスト プラクティスがあります。これは、ブランチがダイアグラムに配置された順序で (上の方がより安定している)、常に下のブランチから上のブランチにマージする必要があることを意味します。これには 2 つの主な利点があります。1 つ目は、安定したコードが安定性の低いコードにマージされず、導入する機能に関連する変更のみが含まれているという意味でブランチが純粋なままであることです。たとえば、D がリリースにマージされた場合、リリースとともにテストする必要があります。そして release には、導入する機能の変更セットとバグ修正の変更セットの両方が含まれます。
これが問題にならないように、私は常により安定したブランチをチェックアウトし、安定性の低いブランチをそこにマージしてそこから移動します。
また、--ours
チェックアウトされた--theirs
ブランチはマージされている他のブランチであることに注意してください。マージの方向を変更すると、それらが参照している変更がスワップされます。