我从git中提取了新的更改，在这个新的更改中有一个迁移文件
def change
add_column :users, :activated_at, :datetime
User.all.each do |user|
user.update(activated_at: user.updated_at)
end
end
现在，通常情况下，如果我想撤消迁移，即删除一列，比如activated_at，我必须运行另一个迁移来完成，这很好
但是，如果我只想删除脚本，即user.update(activated_at: user.updated_at)，我是否必须创建另一个迁移，还是只从迁移中删除脚本。
注意：我不想删除activated_at列，我只想删除脚本
您只需删除代码并在master分支中提交即可。
对于运行此迁移的系统，您可以运行rake任务来运行您想要回滚的任何内容(即将activated_on设置为nil)。或者您可以从rails控制台运行以将其设置为零。
对于新系统，您将克隆并创建数据库&运行迁移，当您删除代码时，它将不会与脚本取得联系。
我的回答有点微妙。简而言之，您会问：您能更改已经运行的迁移吗？一般来说，我建议不要这样做。在您的情况下，这也取决于activated_at字段必须发生什么，我可以想象，只有在用户被"激活"时才会设置它(无论这在您的应用程序上下文中意味着什么)。所以在这种情况下：将其设置为updated_at是错误的，必须"取消设置"？还是以不同的方式设置？因此，无论如何，这都需要迁移。或者，也有可能：迁移尚未在例如您的生产服务器上运行，像这样运行迁移将很难以良好的方式撤消(在这种情况下，它很简单——再次将activated at设置为nil)，然后通过各种方式调整迁移，提交并在部署时运行更好的迁移。但是您将不得不手动恢复/修复迁移运行的所有机器上的情况(您的机器、您的同事、临时测试平台？…)
因此，为了帮助您的决策过程
- 如果你在一个团队中工作，并且队友已经签出了你的代码并运行了迁移，请使用新的迁移来修复它
- 如果您已经部署到任何服务器(测试/暂存/生产)，否则您将不得不修复它，请添加一个新的迁移来修复它
- 如果您没有将代码推送到
master(所有代码都保持在本地)，请随意调整迁移：P
顺便说一句：我见过一些开发人员非常渴望在git中只有"完美"的代码，他们会使用git提供的所有选项来清理代码：回到历史，压缩提交，我不得不承认结果非常清楚。这很有诱惑力，也很容易理解，但如果我们不了解信息(我们是如何到达这里的，为什么？)。同样，进行干净和最少的迁移也很诱人，但就我个人而言，git和您的迁移"显示"了对问题领域日益增长的理解，这并不可耻。我认为这是它被称为"开发"的原因之一：构建软件是一个非常迭代的过程，它不断变化，您的代码(git/history)和迁移可以反映这一点。如果最后一部分过于元和主观，我深表歉意。