基于Rails 5克隆独立数据库ROR应用的注意事项（含Gem管理）

Hey there! Let's break down exactly how to clone and refactor your Rails 5 app into a standalone second project with its own database—perfect that you want to reuse most of your existing work while tweaking the UI. Since you're new to Ruby/Rails, I'll keep this step-by-step and highlight the critical gotchas you need to watch for, especially around gems.

First, let's get a copy of your app and separate it from the original GitHub repo so you can develop independently:

• Clone your existing repo to your local machine if you don't already have a copy:
  git clone https://github.com/your-username/your-original-app.git
• Rename the folder to your new app's name (e.g., mv your-original-app new-app-name)
• Cd into the new folder, then cut the link to the original GitHub repo:
  git remote remove origin
• Create a new empty GitHub repo for the new app, then add it as your new origin:
  git remote add origin https://github.com/your-username/new-app-name.git
• Commit the initial state and push to your new repo:
  git add . && git commit -m "Initial clone of original app for new project" && git push -u origin main

This is crucial to make sure your new app doesn't interfere with the original's data:

• Open config/database.yml—this file tells Rails how to connect to your databases. Update the database names for each environment (development, test, production) to something unique for your new app. For example:

  default: &default
    adapter: postgresql # or mysql2/sqlite3, whatever your original app uses
    encoding: unicode
    pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  
  development:
    <<: *default
    database: new_app_development
  
  test:
    <<: *default
    database: new_app_test
  
  production:
    <<: *default
    database: new_app_production
  

• Create the new local databases with these commands:
  rails db:create
rails db:migrate
  (If you want to reuse seed data from the original app, run rails db:seed—just double-check the seeds make sense for the new project!)
• Note: Keep database-specific gems (like pg or mysql2) as-is unless you want to switch database types—they'll work perfectly with your new database.

You mentioned wanting to keep all code, class names, and gems—so this part is straightforward:

• All your models, controllers, helpers, and business logic can stay exactly as they are. No need to rename classes unless you specifically want to (but you said you want to reuse them, so leave them be!)
• For the homepage: Find your root route in config/routes.rb (it’s probably root 'home#index'). Then edit the corresponding view file (e.g., app/views/home/index.html.erb) to redesign the layout. You can add new partials or assets here too if needed.
• For CSS: If you’re using Rails 5’s default Sprockets asset pipeline, modify app/assets/stylesheets/application.css (or .scss if you use Sass) to update styles. If you want a clean break, create a new stylesheet file and import it in application.css, or override specific classes directly.
  • Pro tip: Use your browser’s dev tools (right-click > Inspect) to target exactly which CSS classes you need to change—this avoids breaking other parts of the app accidentally.

This is where a lot of new Rails devs trip up, so let’s cover this in detail:

• Keep core gems unchanged: All your functional gems (like rails, devise for auth, pundit for permissions) can stay in the Gemfile. Sticking with the original versions will avoid compatibility headaches—no need to upgrade unless you have a specific reason.
• Verify environment-specific gems: Some gems only belong in certain environments (e.g., pry-rails for debugging in development, rspec-rails for testing). Make sure these are still in the correct groups in your Gemfile (like group :development, :test do ... end)—Rails will only load them where they’re needed.
• Remove app-specific gems: If your original app had gems tied to its unique purpose (e.g., a payment gateway only the original uses), delete those lines from the Gemfile if the new app doesn’t need them. Then run bundle install to update your Gemfile.lock.
• Refresh Gemfile.lock: After any Gemfile changes, run bundle install to generate a new lock file specific to your new app. This file locks in exact gem versions—don’t copy the original Gemfile.lock; let Bundler handle it to ensure consistency.
• Check gem configurations: Many gems require setup in config/initializers (e.g., devise.rb, carrierwave.rb). If these have original-app-specific values (like API keys, mailer addresses), update them for the new app. For example, change the mailer sender in devise.rb to something appropriate for your new project.
• Always use bundle exec: When running Rails commands (like rails server or rails db:migrate), prefix them with bundle exec to ensure you’re using the gems specified in your Gemfile. This avoids conflicts with other gems installed on your system.

Don’t skip this—you want to make sure your new app runs independently:

• Start the server with bundle exec rails s and navigate to localhost:3000 to confirm the homepage looks right and loads properly.
• Test core functionality (user signup/login, creating records, etc.) to ensure the reused code works with your new database.
• Hunt for hardcoded values: Use RubyMine’s global search to look for references to the original app’s name, URLs, or email addresses—update any that don’t fit the new project.

内容的提问来源于stack exchange，提问作者Zurch