我正在处理的一个项目迫切需要重构。问题是通常有多个分支（维护、新功能等），我不确定我们是否可以轻松移动、重命名和删除文件和目录并合并更改。我担心当其他人在另一个分支中更新文件时，我会在重构分支中移动文件。我一直希望有一个小窗口，主干有一切，不需要分支，但业务总是需要更改（立即或作为次要版本的一部分）。
我们的源代码控制由 Subversion 管理。在一个分支中彻底改变项目，同时与其他分支保持同步是否容易/可能？我很擅长合并更改以使分支保持最新状态，也许一次只进行小的重构更改就可以了。否则，这真的只能通过留出一些时间我们只进行重构（即没有其他分支）来完成吗？我一直在试图说服企业主我们需要一些时间来重构，虽然他们同意，但现在看来不可能。
关于重构的一个重要事情是它应该始终完成（不仅仅是偶尔一次）。这对于实际代码（分解函数、删除重复代码等）似乎是可行的，但我对适当地重命名和分组文件不太有信心。
【问题讨论】：
标签： svn refactoring branching-and-merging
这在 SVN 中是可行的，但我可以告诉你，你会面临很多不同的问题。如果您真的希望重构到每个分支，请三思而后行？将重构的代码合并到发布分支（这是用于发布生产版本的小修复的维护分支）似乎并不合理。
虽然 SVN 可以让你从任意分支合并到任意分支，但在分支和起源分支之间合并总是更合理。因此，如果你有这样的事情：
Rel-1.0 /---------------->
Rel-1.1 / /------------------->
Trunk --------------------------------*------>
FeatureA \--------> \ \ ^ (rev. X)
FeatureB \--> \ |
Refactor \--->
与其在 Refactor 中进行重构工作并将其合并到每个其他分支，不如将 Refactor 分支中的更改重新集成到 Trunk（假设在修订版 X 中），然后将修订版 X 从 Trunk 合并到其他分支更合理需要这个改变。对于发布分支（Rel-1.0、Rel-1.1），它很可能是一个选择。对于功能分支 A/B，它将赶上 Trunk（通过合并 Trunk 中的所有东西）。
请注意，如果您的分支偏离主干更多，合并会变得更加困难。因此，如果您确实需要合并重构代码以发布分支（这很可能非常偏离主干），请三思。
还请注意，SVN 中的重命名跟踪并没有很好地实现。例如，您将主干中的文件 F 重命名为 FNew，SVN 处理的是通过从 F 复制添加 FNew，然后删除 F。如果将其合并到分支，afaik，SVN 所做的是通过从主干/复制添加分支/FNew F，并删除分支/F。因此，如果您曾经修改过分支/F，对于较新版本的 SVN（可能 >=1.5），它会产生树冲突，而在旧版本的 SVN 中您甚至会丢失修改。尽管较新的版本处理得更好一些，但它们都没有处理“正确”重命名的合并（将分支/F 移动到分支/FNew）。这将导致您在合并时付出额外的努力，如果两个分支偏离很多，合并会更加困难。
【讨论】：
如果你彻底改变一个分支，你在合并你的代码时肯定会遇到问题，尤其是当其他人对相同的文件进行更改时。
我会在这里推荐一些巧妙的安排。您必须处理当前未处理的部分代码。或者，将重构作为正常业务运营的一部分。
【讨论】：
我认为你可以只修改一个分支，创建补丁文件并使用相同的补丁文件来更新所有其他分支？
【讨论】：