ruby-on-rails - 在反复复制 Rails 安装后运行它有什么问题吗？
问题描述
我的基本问题是：如果我重复复制一个 Rails 应用程序，所以有很多代相同的 repo（即 Rails 应用程序的目录和文件的各种迭代），我需要做些什么来确保服务器正常运行和避免重大问题？
我正在编写一个学习应用程序，让用户了解编程任务。现在它只支持单文件任务。接下来我想添加对多文件任务的支持，涉及 HTML/CSS/JS 和 Rails 任务（例如，“添加执行某某功能的模型”或“为某某功能添加 Minitest 测试” ）。用户需要直接编辑 Rails 代码，然后我的应用程序将自动运行服务器并显示结果。在回答每个问题（即执行每个任务）后，我的应用程序将根据需要自动向下迁移数据库并从 tarball 重新复制 repo——基本上，为用户下次处理任务做准备。（好吧，我希望这是个好主意。）
由于 Rails 应用程序如此庞大和复杂，因此为每个问题构建和添加单独的 Rails 应用程序当然是不可行的。相反，我将有许多基于相同存储库（安装）的问题/任务。在回答每个问题后（即执行每个任务），数据库将根据需要向下迁移，并从 tarball 重新复制 repo。到目前为止，一切都很好？（我预计使用 Git 会出现问题......所以我只会使用Minitar。）
但当然，当我提出其他问题集群时，我将不得不制作同一个 repo 的其他版本（使用相同的数据库，或者可能是一个副本）。例如，我可能想要一堆与在 Rails 中使用 AJAX 相关的问题/任务，为此我需要以各种方式准备安装。但是，如果我只是在具有自己任务的先前存储库的副本上构建，那么复制过程是否会导致以后的存储库及其任务出现问题？
我做了一些测试。我已经确认，如果我只是简单地执行cp -r repo1/ repo2/然后运行rails s，repo2后者的服务器将正常启动。虽然写入的数据repo2没有出现在 中repo1，但我无法创建同名模型（这有点令人费解）。我想这可能是一些问题的问题——即，我真的不希望它们从一个相同的数据库运行所有的 repos，即使以后的数据库版本是基于早期版本的。所以每当我复制一个 repo 时，我想我会想要复制数据库，如此处所述。听起来对吗？
在构建此功能时，我还需要做些什么来防止与重复复制同一仓库（和数据库）的不同迭代相关的问题？
解决方案
我认为你让它变得比它需要的更复杂。这一切都可以在 git 中通过利用 git 功能分支（例如 question-1、question-2）为每个派生并将其与 rails rake 数据库任务（例如 rake db:drop、rake db:create、rake db:migrate）在 git 中完成, rake db:seed，以确保为每个分支正确引导您的数据库。
另一种方法是将最终数据库状态的 SQL 转储添加到每个功能分支，并通过 rake 任务加载它们以将数据库引导到所需状态。