假设我有一个功能分支。出于任何原因，我需要使用主干的最新开发来更新它（其中包括比我的分支更多的开发）。
您会采用哪种策略？ 1/ 将主干的开发合并到我的分支中 2/ 从最新的主干创建一个新分支并应用在我的分支中完成的开发。
使用解决方案1，当我将分支重新集成到主干时会导致问题吗？如果我在第一次合并（trunk->branch）期间解决了冲突，我是否必须在第二次合并（branch->trunk）期间再次解决它？
您建议哪种解决方案？
提前感谢您的回答。
【问题讨论】：
标签： svn merge synchronization branch
最好从最新的主干创建一个新分支，并将您的功能分支合并到这个新分支中。这样，当你将你的特性分支合并到这个主干副本中时，你正在合并你自己做的代码：你很熟悉的东西。如果与此有任何冲突，您可以很好地解决它们。
稍后，您可以将这个新分支合并回主干。同样，您将合并您熟悉的更改。
这是一个非常简单的合并策略，因为所有的合并都朝着一个方向：
【讨论】：
您可以从与主干同步开始，因为这是这样做的正常方式，然后看看会发生什么。如果您发现解决同步冲突有太多困难，您可以恢复到干净的分支并尝试解决方案 2。
只有当您真的准备好重新集成时，才可能首选解决方案 2，否则您将有额外的工作需要同步。或者然后您的开发分支将从分支 1 更改为您合并的分支 2，下次您将创建一个分支 3，依此类推...
关于解决冲突，您始终可以采用安全策略或“他们的变化”或“他们的全部”。提醒您，在您的工作目录中，您可以搞砸事情并恢复。 您最终可以接受所有“他们的冲突”并明确地重放您的更改，这将具有与解决方案 2 相同的效果，而无需创建临时分支。
另外，trunk 上的很大一部分更改可能与您的开发无关，如果您的更改很少，那么无论trunk 上还有多少其他更改，您的冲突代码都不会超过你写的代码。
关于您的第二个问题：如果它在您重新集成时会导致问题，那么不应该提供您使用 --reintegrate 选项。 无论如何，即使它会，你也不应该担心，因为“合并”或“合并 --reintegrate”的结果只适用于你的工作目录。这样您就可以测试和修复或恢复。
cd workdir
svn merge ^/trunk
#resolve conflicts
svn ci
svn update
svn status -q
# to ensure there is no pending changes
svn switch ^/trunk
svn merge --reintegrate ^/branches/your_branch
# resolve conflicts and test or revert
# and only if you are satisfied:
svn ci
svn up
# if your not satisfied:
svn revert
svn merge --reintegrate ^/branches/your_branch
# try resolve conflict in an another way ...
【讨论】：
感谢您的回答。
我问是因为解决方案 2 有一个缺点。该功能的开发分为许多分支，以防我必须同步多次。修改的历史有点复杂。
其实我更喜欢方案 2。
【讨论】：