想象一下，我有一個功能分支。出於任何原因，我需要更新幹線的最新發展（其中包括比我的分支更多的發展）。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 - 從主幹創建一個新分支，並將其中的更改合併到它。這樣，如果出現問題，你還沒有污染你的原始分支。或者，只需在合併之前標記您當前的分支，並且您可以輕鬆地還原爲標記。 –