私はTortoiseとのマージを知っています。SNVについては議論されていますが、私の状況は解りません。マージウィザードを使用してdevブランチをトランクにマージすることができますが、マージしたい場合は適切なワークフローは何ですか？がトランクに分岐しますか？Tortoise SVN複数のブランチをトランクにマージ
私の状況では、プロジェクトトランクから3つのdevブランチ（開発者ごとに1つ）を作成しました。最初は、devブランチとトランクは同一でした。開発者もプロジェクトの別の領域で作業しているため、複数の人が同じファイルを使用して作業していません。たとえば、トランク、b1、b2、およびb3は、トランク= b1 = b2 = b3となります。
開発の後、各devブランチからの変更をトランクにマージしたいと思います。これは私が混乱しているところです。私はあなたが単に同じ祖先を共有し、何が変わるべきかを知るのに十分なほど賢いので、各ブランチを一度に1つずつトランクにマージすることができます（次のトランクをマージする前に各ブランチから変更をコミットすること）。だから、私はまた、あなたが（私は亀がないように十分にスマートだと思った）問題が上書きされないようにトランクにマージ、その後、他のdevの枝にdevのブランチの変更をマージする必要があることを読んだことがある
b1 -> merge to trunk -> commit trunk (now trunk has b1 changes)
b2 -> merge to trunk -> commit trunk (now trunk has b1 and b2 changes)
b3 -> merge to trunk -> commit trunk (now trunk has b1, b2, and b3 changes)
。したがって：
b3 -> merge to b2 -> commit b2 (now b2 has b3 changes)
b2 -> merge to b1 -> commit b1 (now b1 and b2 and b3 changes)
b1 -> merge to trunk -> commit trunk (now trunk has b1, b2, and b3 changes)
1つの方法が他の方法よりも優れているか、または欠陥があるかどうかを教えてください。私の関心事は、あるブランチからの変更をマージし、別のブランチからの変更をマージし、最初のマージ操作からの変更を元に戻したり、メタデータの問題を引き起こしたりすることです。
私は25755とのSubversion 1.8.10を構築し、TortoiseSVNのバージョン1.8.8を使用しています。
ありがとうございました！
あなたが従うワークフローに関係なく、変更を取り消す心配はありません。 Subversionはマージの競合にフラグを付け、コミットする前に変更を確認することができます。マージ操作を含め、作業コピー上の操作はいつでも元に戻すことができます。あなたが変更をコミットするときだけ記録されます。つまり、適切なワークフローを使用することで、合併困難から救うことができます。それについての詳細は私の答えを見てください。 – RjOllos