git - ブランチをマスターにマージするGit

Question

マスターから分岐して機能を開発したブランチがある場合...マスターにマージする場合、2つの異なるアプローチを聞いたことがあります。

1. 最初にマスターを機能ブランチにマージし、次にブランチをマスターにマージし直します。
2. ブランチをマスターにマージします。

誰かが私にどちらの方法が良いか、そして最初の方法に実際の利益があるかどうか教えてもらえますか？

または、より良い方法がある場合はどうなりますか？

Answer 1

master からfeature-sevを作成し、その間にfeature-ericを作成するとします。私のブランチはあなたのものと同じファイルを変更します。実際、私たちの git クライアントが理解できるほど巧妙ではない方法で重複しています。最初に開発を終了し、変更をマージします。

この状況では、競合を解決するように求められることは避けられません。

CONFLICT (content): Merge conflict in stackoverflow.html
Automatic merge failed; fix conflicts and then commit the result.

(1) で行った場合、 master をブランチにマージし、すべてが適切に見えることを確認したら、feature-sevのマージ コミットを介して競合を解決します。解決中に間違いを犯した場合は、マスターに直接変更を加えることなくロールバックできます。これはいい。

(2) を選択した場合は、master に対して直接マージ コミットを行うことで競合を解決できます。少しでも間違えると、マスターが壊れます。これは悪いです。

Answer 2

私はそれが依存すると思います;-)

考慮すべきいくつかの事柄：

• マージ後に機能ブランチが必要になりましたか？masterもしそうなら、それにマージするだけでなく、にマージして戻すと便利かもしれませんmaster。そうでない場合は、とにかく削除する場合は、機能ブランチにマージすることはあまり意味がありません。
• masterブランチのローカル作業コピーを壊しても大丈夫ですか？masterそうでない場合は、手動で解決する必要のある多くの競合が発生する可能性のあるコードをマージしないようにする必要があります。よろしければ続行します。

一般的に、それはあなたがgitをどのように扱うかに依存すると思います。

私は通常、機能ブランチを一時的にのみ使用し、機能を正常に終了してにマージした後で削除するためmaster、通常は直接master他のブランチにマージして後で削除します。

一方で、逆にすると便利な場合もあると思います。しかし、強い理由がない限り、私はそれを避けようとします。1つのマージで十分です;-)。

Answer 3

理論的には、違いはありません。あるブランチに一連の変更があり、それを別のブランチの一連の変更と組み合わせています。それらの変更がどこで終わるかは問題ではありません。

実際には、競合を解決するための分離された場所が得られるため、変更をフィーチャー ブランチにマージすることをお勧めします。最初のコミット後に解決される微妙な競合がしばしばあるため、機能ブランチが長期間開発されている場合、これは特に重要です。

最善の方法は、マスター ブランチから機能ブランチに定期的に更新を行い、機能開発の最後に競合が発生する可能性を減らすことです。