更新：我真的不是在寻找如何改变公司流程的技巧，如何将问题抛给别人等等。相反，我希望找到是否有一些晦涩的Java知识可以允许我滥用枚举作为临时解决方法。在问了这个问题后，我设法找到了一个安静的时期，释放了我的零钱。但我仍然很好奇，在这种情况下，Java 的黑暗角落里是否有什么东西可以提供帮助。
我有一个巨大的、旧的（但仍在积极开发的）Java 代码库，其中包含许多包，我需要在它们之间移动一个枚举。
类中有这个枚举：
package com.foo.bar;
public class ParentClass
{
public Enum MyEnum
{
ONE, TWO;
}
}
此枚举在整个应用程序中广泛使用。我需要从父类中提取它并将它移动到不同的包中：
package com.enums;
public Enum MyEnum
{
ONE, TWO;
}
如何做到这一点的标准方法是使用 IDE 进行简单重构。哪个有效。但是...这导致许多地方发生变化，并且由于代码库是由不同的团队和许多人积极开发的，所以我不断遇到合并冲突，这个枚举的新用法不断出现，等等。所以我陷入了打地鼠的境地。我更新我的更改，运行测试套件并构建它，但在此之前（整个循环至少需要一天，而不是谈论新的代码审查），我最终遇到了另一个冲突。冲洗，重复。
告诉所有人在我合并时停止工作是不可能的。如果它是一个普通的类而不是一个枚举，我可以尝试使用继承：将它移动到新的位置并用一个空的子类替换原来的位置，然后一个一个地处理用法。但是 Java 枚举不能扩展。
有什么办法可以将此更改分为多个阶段（这样我就不需要更改所有使用它的导入），而不必在原子更改中一次全部完成？
这是您上面评论的副本，因为我的回答将引用它。
@QBrute: 项目太大了，每天几千人在做，一次要改的地方太多了。每次我解决一个合并冲突时，大约需要一天时间才能真正合并它（测试构建、审查...），到那时，新的冲突会弹出，所以我无法合并，不得不解决新的冲突.而且我不可能改变公司的工作流程或让每个人都停下来几天
首先我要说的是，根据您提供给我们的少量信息，您的同事和公司处理包裹重新安排的流程似乎是这里的错误。但是你也提到你不能真正轻易地改变公司的工作流程。
让我印象深刻的部分是你说测试合并冲突修复需要一整天。也许，与其自己更改代码，不如添加一个单元测试。
单元测试应该简单。
当这些测试失败时，添加一个 braindead 简单的错误消息，告诉您的同事 EXACTLY 他们需要做什么来修复这个单元测试。单元测试还应该有助于减慢传入代码的速度，因为失败的单元测试应该会阻止新版本的发布。另外，一个失败的单元测试应该允许它显示在你的开发人员的前面和中心（假设他们检查/响应单元测试失败）。
由于添加单元测试是一种非功能性更改（甚至不应该存在于您部署的库/可执行文件中），您可以跳过整个测试/审查/部署周期，这似乎会花费您很长时间。你只需提交然后合并。
不过，基本上每个项目都需要这样做。不过应该是简单的复制和粘贴。