想象一下，我有一个功能分支。出于任何原因，我需要使用主干的最新发展进行更新（其中包括比我的分支更多的开发）。
您会采用哪种策略？ 1 /从我的分支合并到我的分支机构的发展 2 /从最新的主干创建一个新的分支，并应用我分支中的开发。
使用解决方案1，当我将分支重新整合到主干中时，它会引起问题吗？如果我在第一次合并（trunk-＆gt;分支）期间解决冲突，我是否必须在第二次合并（branch-＆gt; trunk）期间再次解决？
您建议采用哪种解决方案？
提前感谢您的回答。
答案 0 :(得分：0)
最好从最新的主干创建一个新分支，并将您的功能分支合并到这个新分支中。这样，当您将功能分支合并到此主干副本中时，您将合并自己执行的代码：您熟悉的内容。如果与此有任何冲突，您可以很好地解决它们。
稍后，您可以将此新分支合并回主干。同样，您将合并您熟悉的更改。
这是一个非常简单的合并策略，因为所有合并都朝着一个方向发展：
答案 1 :(得分：0)
您可以从与trunk同步开始，因为这是正常的方法，并查看appen。如果您发现解决同步冲突的困难太多，您可以恢复到干净的分支并尝试解决方案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 :(得分：0)
感谢您的回答。
我在问，因为解决方案2存在一个缺点。如果我必须多次同步，该功能的开发将拆分为多个分支。修改的历史有点复杂。
我更喜欢解决方案2。