我正在努力的项目迫切需要重构。问题是通常有多个分支（维护，新功能等），我不太确定我们可以轻松移动，重命名和删除文件和目录并合并更改。我担心的是，我会在重构分支中移动文件，而其他人正在另一个分支中更新文件。我一直希望有一个小窗口，其中主干拥有一切，不需要分支，但业务总是需要更改（立即或作为次要版本的一部分）。
我们的源代码控制是使用Subversion管理的。是否容易/可能在一个分支中彻底更改项目，同时保持变更与其他分支同步？我非常擅长合并更改以使分支保持最新，并且可能只是一次进行小的重构更改。否则，这真的只能通过留出一些时间来完成，我们只会在重构（即没有其他分支）吗？我一直试图说服企业主说我们需要一些时间来重构，虽然他们同意，但现在似乎不可能。
重构的一个重要方面是它应该始终完成（而不仅仅是一次）。这似乎与实际代码（分解函数，删除重复代码等）相关，但我对适当重命名和分组文件并不是很有信心。
答案 0 :(得分：3)
可以在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中跟踪重命名并不是很好。例如，你将trunk中的文件F重命名为FNew，SVN通过从F复制添加FNew，并删除F.如果你将它合并到分支，afaik，SVN所做的是通过从trunk复制添加branch / FNew / F，并删除分支/ F.因此，如果您曾经修改过分支/ F，对于较新版本的SVN（可能> = 1.5），它将产生树冲突，而在较旧版本的SVN中，您甚至会丢失修改。虽然较新的版本处理得更好，但它们都没有处理合并以“正确”重命名（将分支/ F移动到分支/ FNew）。这将导致您在合并时付出额外的努力，并且在两个分支偏离很多的情况下导致合并更加困难。
答案 1 :(得分：1)
如果你彻底改变一个分支，你肯定会在重新合并你的代码时出现问题，特别是当其他人正在对同一个文件进行更改时。
我建议在这里做一些聪明的安排。您将不得不处理当前未处理的部分代码。或者，将重构作为正常业务运营的一部分。
答案 2 :(得分：-1)
我认为您可以修改一个分支，创建补丁文件并使用相同的补丁文件来更新所有其他分支？