Question
How to Undo a Rails Generator: Reversing `rails generate` in Ruby on Rails
Question
In Ruby on Rails, how can I undo a previous rails generate command?
I want to remove the files that the generator created and reverse any code changes it made, especially in files such as config/routes.rb. I am not mainly concerned with reverting the database right now; I want to clean up generated files and configuration changes automatically where possible.
For example, if a generator added resource routes, controller files, model files, tests, or other related boilerplate, how can I reverse those changes safely?
Short Answer
By the end of this page, you will understand how Rails generators can be reversed using the destroy command, what kinds of files and code changes Rails can undo automatically, what it does not always clean up, and how to safely verify and complete the cleanup manually when needed.
Concept
Rails generators are tools that create boilerplate code for common tasks such as models, controllers, scaffolds, migrations, tests, and routes.
When you run a command like:
rails generate scaffold Post title:string body:text
Rails creates multiple files and may also modify existing files such as:
config/routes.rb- test files
- helper files
- assets
- migration files
The matching concept for undoing this is the generator reversal. In Rails, many generators support the opposite operation through:
rails destroy ...
This tells Rails to run the inverse of the generator so it can:
- delete files it previously created
- remove inserted route lines where possible
- reverse some generated boilerplate changes
This matters because generators often touch multiple parts of a project. Manually deleting files can leave behind broken routes, orphaned tests, helper modules, or configuration changes. Using the matching destroy command is safer and faster because Rails knows what the original generator likely created.
However, generator reversal is not magical. It works best when:
- you use the exact matching generator command
- the generated files were not heavily edited afterward
- the changes follow the standard generated structure
If a file was changed manually after generation, Rails may not perfectly restore it. In those cases, manual review is still important.
Mental Model
Think of a Rails generator like a stamp that places a set of matching pieces into your project:
- a model file
- a controller file
- route entries
- tests
- views
- migrations
Using rails destroy is like using the matching stamp remover. It knows where the stamp usually placed those pieces and tries to remove them.
But if you later cut, move, or rewrite those pieces by hand, the remover may no longer recognize everything perfectly. So destroy is helpful, but you should still inspect the project afterward.
Syntax and Examples
The basic syntax is:
rails destroy GENERATOR_NAME arguments
It should usually mirror the original generate command.
Example: undo a scaffold
If you originally ran:
rails generate scaffold Post title:string body:text
You can reverse it with:
rails destroy scaffold Post
Rails will try to remove files such as:
app/models/post.rbapp/controllers/posts_controller.rb- view files under
app/views/posts/ - test files
- helper files
- migration files created for the scaffold
- route entries added to
config/routes.rb
Example: undo a model generator
If you ran:
rails generate model Comment body:text post:references
You can reverse it with:
rails destroy model Comment
This usually removes:
- the model file
- test/spec files
Step by Step Execution
Consider this command:
rails generate scaffold Article title:string published:boolean
Rails may do work like this:
- Create
app/models/article.rb - Create a migration file for
articles - Create
app/controllers/articles_controller.rb - Create view templates
- Create tests or specs
- Add a route such as:
resources :articles
Now you run:
rails destroy scaffold Article
Rails then attempts to reverse those steps:
- Remove
app/models/article.rb - Remove the migration file it generated
- Remove
app/controllers/articles_controller.rb - Remove the related views
- Remove tests or specs
- Remove the matching
resources :articlesline fromconfig/routes.rb
Small trace example
Suppose config/routes.rb became:
Real World Use Cases
Here are common situations where reversing a generator is useful:
1. You generated the wrong resource
You meant to create Article but generated Articles or used the wrong attributes.
rails destroy scaffold Article
Then regenerate it correctly.
2. You are experimenting during development
While prototyping, you may create scaffolds just to test ideas. If you decide not to keep one, destroy helps remove the boilerplate quickly.
3. You created a controller with the wrong name or namespace
For example, you generated Admin::ReportsController incorrectly. Destroying it can remove the generated folder structure and related files.
4. You want to keep the database but remove app code
Sometimes you mainly care about removing generated controllers, views, helpers, and route entries. destroy can handle much of the app-level cleanup, and you can decide separately what to do with migrations or schema changes.
5. You want safer cleanup than manual deletion
Deleting only the obvious files may leave behind:
- stale routes
- test failures
- unused helpers
- broken constants referenced elsewhere
Using Rails reversal reduces that risk.
Real Codebase Usage
In real Rails projects, developers commonly use rails destroy as part of a careful cleanup workflow rather than assuming it will solve everything automatically.
Typical workflow
- Run the matching
rails destroycommand. - Check the terminal output to see what was removed.
- Review
git diffto inspect remaining changes. - Manually clean up anything custom that Rails could not reverse.
- Run tests and boot the app.
Common patterns in teams
Use Git as the safety net
Developers usually commit before running large generators. That way, if the cleanup is incomplete, they can inspect or revert changes safely.
Prefer exact inverse commands
If the original command was:
rails generate scaffold Invoice total:decimal paid:boolean
the team will typically use:
rails destroy scaffold Invoice
instead of manually deleting files.
Review route changes explicitly
Even though Rails often removes generated routes, developers still inspect config/routes.rb, because routes are frequently customized after generation.
Separate app cleanup from database cleanup
In real codebases, application files and database state are often handled separately:
Common Mistakes
1. Using destroy with the wrong generator type
Broken approach:
rails generate scaffold Post title:string
rails destroy model Post
This removes only part of what scaffold created.
Better approach:
rails destroy scaffold Post
2. Expecting database changes to be fully ignored
A generator may create a migration file. Destroying the generator can remove the migration file, but if you already ran the migration, your database schema may still have changed.
You may also need commands like:
rails db:rollback
or a new corrective migration, depending on the situation.
3. Assuming manual edits will be reversed perfectly
If you changed generated files after creation, Rails may not know how to undo your custom edits.
For example, if you changed routes from:
resources :posts
into:
resources :posts do
resources :comments
end
destroy may not remove everything exactly as you expect.
Comparisons
| Approach | What it does | Best for | Limitations |
|---|---|---|---|
rails destroy | Reverses a matching generator | Removing standard generated files and route changes | May not fully undo manual edits |
| Manual file deletion | Deletes selected files by hand | Very targeted cleanup | Easy to miss routes, tests, helpers, or configs |
git checkout / git restore | Restores files from version control | Undoing recent uncommitted changes exactly | Only works well if changes were tracked in Git |
rails db:rollback | Reverses database migrations | Undoing schema changes | Does not remove controller, model, view, or route files |
vs
Cheat Sheet
# General form
rails destroy GENERATOR_NAME Name
# Undo a scaffold
rails destroy scaffold Post
# Undo a model
rails destroy model Post
# Undo a controller
rails destroy controller Posts
Rules to remember
- Use the same generator type you originally used.
- Usually use the same resource/class name.
- Rails can often remove route entries it inserted.
- Rails may remove generated migration files.
- If the migration was already run, database cleanup may still require
rails db:rollbackor a new migration. - Always inspect
config/routes.rbafter destroying. - Always check
git diffand run tests.
Good cleanup workflow
git status
rails destroy scaffold Post
git diff
bundle exec rails routes
bundle exec rails test
Edge cases
- Custom-edited routes may not be removed cleanly.
- Renamed files or moved files may confuse the destroy step.
- Manual deletions before
destroycan leave partial cleanup.
FAQ
How do I undo rails generate scaffold?
Run the matching destroy command:
rails destroy scaffold ModelName
This usually removes generated files, views, tests, and route entries.
Does rails destroy remove changes from routes.rb?
Usually, yes, if the route was inserted by the generator in a recognizable way. If you edited the route manually afterward, you may need to clean it up yourself.
Does rails destroy undo database migrations too?
It can remove the generated migration file, but if the migration was already run, the database schema may still need a rollback or a new migration.
Do I need to pass the attributes again when destroying?
Usually no. For common generators like scaffold or model, the name is typically enough:
rails destroy scaffold Post
What if I already edited the generated files?
Rails will still try to remove them, but custom edits in shared files like routes.rb may not be reversed perfectly. Review the changes manually.
Is manual deletion enough?
Sometimes, but it is easy to miss helpers, tests, route entries, and other generated pieces. rails destroy is usually safer.
What is the safest way to undo a generator?
Mini Project
Description
Create and then safely remove a small generated Rails resource so you can see how rails destroy cleans up files and route changes. This project demonstrates the difference between generator cleanup and database rollback, and helps you build a safe workflow using inspection and verification.
Goal
Generate a simple Rails resource, reverse it with rails destroy, and verify which files and route changes were removed.
Requirements
- Generate a Rails scaffold named
Bookwith at least one attribute. - Inspect which files and route changes were created.
- Run the matching
rails destroycommand for that scaffold. - Verify that the generated files were removed and
config/routes.rbwas updated. - Check whether any migration or database cleanup is still needed.
Keep learning
Related questions
Calling an Overridden Monkey-Patched Method in Ruby
Learn how to call the original method when monkey patching in Ruby, including alias_method patterns, examples, pitfalls, and practical usage.
Difference Between require and include in Ruby
Learn the difference between require and include in Ruby, when to load a file, and when to mix module methods into a class.
Fixing Ruby Gem Native Extension Errors: mkmf.rb Can't Find Header Files for Ruby
Learn why Ruby gem installs fail with missing ruby.h, how native extensions work, and how to fix header file errors on Linux servers.