想象一下，我有一个功能分支。出于任何原因，我需要更新干线的最新发展（其中包括比我的分支更多的发展）。SVN - 同步分支的最佳策略
您会采用哪种策略？ 1 /合并到我的分支中从主干发展 2 /从最新干线创建一个新分支并应用我分支中完成的发展。
对于解决方案1，当我将分支重新集成到主干时，是否会导致问题？如果我在第一次合并（trunk-> branch）过程中解决了冲突，那么在第二次合并（branch-> trunk）期间，我是否必须再次解决它？
你建议哪种解决方案？
在此先感谢您的答案。
最好从最新的trunk中创建一个新分支，并将你的特性分支合并到这个新分支中。这样，当你将你的特性分支合并到这个trunk的副本中时，你正在合并你自己的代码：你熟悉的东西。如果与此有任何冲突，那么你有能力解决它们。
稍后，您可以将此新分支合并回主干。再次，您将合并您熟悉的更改。
这是一个非常简单的合并策略，因为所有的合并在一个方向走：
你可以开始与主干同步，因为这是这样做的正常方式，并且看到什么appen。如果您发现解决同步冲突时遇到太多困难，则可以恢复到干净的分支并尝试解决方案2.
如果您真的准备好重新集成解决方案2，则只能选择解决方案2，否则您将需要额外的工作同步。或者您的开发分支将从分支1更改为您合并的分支2，并且下一次您将创建分支3等等......
关于解决冲突，您始终可以采用安全策略或“他们的改变“或”全部“。提醒一下，在你的工作日，你可以搞砸事情并恢复。 您最终可以接受所有'他们的冲突'并明确地重放您的更改，这将与解决方案2具有相同的效果，而无需创建临时分支。
另外，主干上的大部分更改可能与您的开发没有关系，如果您的更改很少，则无关于主干上的其他更改，您的代码数量不会超过数量你写的代码。
关于你的第二个问题：如果重新集成时它可能导致问题，否则它不应该提供你使用--reintegrate选项。 无论如何，即使它会，你不应该担心，因为'merge'或'merge --reintegrate'的结果只适用于你的workdir。以便您可以测试并修复或还原。
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。
如果这将是一个混乱的合并，那么我会完全推荐策略2 - 从主干创建一个新分支，并将其中的更改合并到它。这样，如果出现问题，你还没有污染你的原始分支。或者，只需在合并之前标记您当前的分支，并且您可以轻松地还原为标记。 –