2

メインブランチと開発ブランチがあります。両方に変更を加えてチェックインします。メインから開発にマージしてチェックインします。次に、開発からメインにマージします。対立があります。これはどのように可能ですか?

4

1 に答える 1

3

ある方向でのマージの競合を解決することは、別の方向でのマージに必ずしも適切ではありません。多くのワークフローでは、基本的に2つのブランチをできるだけ類似させるためにマージしています。たとえば、開発ブランチから本番ブランチに変更を加えたり、重大なバグ修正を本番ブランチから開発ブランチに戻したりします。この種のワークフローでは、通常、2つのブランチをマージするときに分岐したくないので(結局、両方のブランチでその重大なバグ修正が必要です)、マージの競合を両方の時間で解決する必要がある理由は明らかではありませんが、それは確かですブランチを操作するときのワークフローはこれだけではありません。

以前は、別のプロジェクトで作業しているグループと共有するユーティリティライブラリがいくつかあるJavaプロジェクトで作業していました。ある時点で、私たちの図書館はさまざまな理由で彼らの図書館から分岐する必要があったので、私たちは彼らのプロジェクトのブランチを取り、両方のグループが図書館に独自の変更を加えました。バグを修正することもあれば、新しい機能を追加することもあるので、頻繁に相互にマージしました。

ここで、私たちのブランチから彼らのブランチへのマージの結果は、必ずしも彼らのブランチから私たちのブランチへのマージの結果である必要はないことがわかります。いくつかの新しいメソッドを追加し、おそらくいくつかのバグを修正したファイルがあったとしましょう。そして、彼らがいくつかの異なるメソッドを追加したと仮定しましょう。彼らが私たちの変更をブランチにマージすると、マージの競合が発生し、バグ修正を取得したが、新しいメソッドを必要としなかったために取得しなかったと仮定します。マージを実行して変更をブランチに取り込むと、マージの競合が発生します。これにより、メソッドをファイルに取り込むことができます。

TFSが、ブランチから私たちへのブランチからの結果に基づいて、ブランチから私たちへのマージについて何らかの仮定を行うとしたら、それは不正確になります。

于 2011-05-06T17:12:04.687 に答える