blocks|key|283796|text|在任何分支中添加新迁移时，请运行rake+db:migrate并同时提交迁移和+db/schema.rb|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|BOLD|entityRanges|data|283797|如果这样做，在开发中，您将能够切换到具有不同迁移集的另一个分支，并简单地运行rake+db:schema:load。|283798|请注意，这将重新创建整个数据库，并且现有数据将丢失。|283799|您可能只想在一个非常小心的分支上运行生产，所以这些步骤在那里不适用(只需像往常一样在那里运行rake+db:migrate+)。但在开发过程中，从模式重新创建数据库应该没什么大不了的，这正是rake+db:schema:load要做的。|283800|entityMap^0|G|F|14|C|12|1|0|12|J|0|6|J|0|1A|F|2N|J|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]|$9|R|A|S|B|C]|$9|T|A|U|B|D]]|E|@]|F|$]]|$1|G|3|H|5|6|7|V|8|@$9|W|A|X|B|C]]|E|@]|F|$]]|$1|I|3|J|5|6|7|Y|8|@$9|Z|A|10|B|D]]|E|@]|F|$]]|$1|K|3|L|5|6|7|11|8|@$9|12|A|13|B|C]|$9|14|A|15|B|C]]|E|@]|F|$]]|$1|M|3|-4|5|6|7|16|8|@]|E|@]|F|$]]]|N|$]]

When you add a new migration in any branch, run <code>rake db:migrate</code> and commit both the migration and <code>db/schema.rb</code>

If you do this, in development, you'll be able to switch to another branch that has a different set of migrations and simply run <code>rake db:schema:load</code>.

Note that this will recreate the entire database, and existing data will be lost.

You'll probably only want to run production off of one branch which you're very careful with, so these steps don't apply there (just run <code>rake db:migrate</code> as usual there). But in development, it should be no big deal to recreate the database from the schema, which is what <code>rake db:schema:load</code> will do.

blocks|key|281572|text|您希望为每个分支保留一个"db环境“。请看一下涂抹/清理脚本，以指向不同的实例。如果数据库实例用完了，让脚本剥离一个临时实例，这样当你切换到一个新的分支时，它已经在那里了，只需要通过脚本重命名即可。数据库更新应该在您执行测试之前运行。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|281573|希望这能有所帮助。|281574|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

You want to preserve a "db environment" per branch. Look at smudge/clean script to point to different instances. If you run out of db instances, have the script spin off a temp instance so when you switch to a new branch, it's already there and just needs to be renamed by the script. DB updates should run just before you execute your tests.

Hope this helps.

blocks|key|287397|text|如果您有一个不容易复制的大型数据库，那么我建议您使用普通的迁移工具。如果你想要一个简单的过程，这是我推荐的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|287398|287399|在切换分支之前，回滚(rake+db:rollback)到分支点之前的状态。然后，在切换分支之后，运行db:migrate。这在数学上是正确的，只要您编写down脚本，它就会工作。|unordered-list-item|offset|length|style|CODE|287400|如果您在切换分支之前忘记了执行此操作，通常您可以安全地切换回、回滚和再次切换，所以我认为作为一种工作流，它是可行的。|287401|如果您在不同分支中的迁移之间存在依赖关系...嗯，你得好好想一想。|287402|287403|entityMap^0|0|0|B|G|1F|A|25|4|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|R|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|S|8|@$F|T|G|U|H|I]|$F|V|G|W|H|I]|$F|X|G|Y|H|I]]|9|@]|A|$]]|$1|J|3|K|5|E|7|Z|8|@]|9|@]|A|$]]|$1|L|3|M|5|E|7|10|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|11|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|12|8|@]|9|@]|A|$]]]|P|$]]

If you have a large database that you can't readily reproduce, then I'd recommend using the normal migration tools. If you want a simple process, this is what I'd recommend:

<ul>
<li>Before switching branches, rollback (<code>rake db:rollback</code>) to the state before the branch point. Then, after switching branches, run <code>db:migrate</code>. This is mathematically correct, and as long as you write <code>down</code> scripts, it will work. </li>
<li>If you forget to do this before switching branches, in general you can safely switch back, rollback, and switch again, so I think as a workflow, it's feasible. </li>
<li>If you have dependencies between migrations in different branches... well, you'll have to think hard.</li>
</ul>

blocks|key|3210182|text|我完全体验了你在这里吃的皮塔饼。考虑到这一点，真正的问题是所有分支都没有回滚某些分支的代码。我在django的世界里，所以我不太了解rake。我在玩弄这样一种想法，即迁移存在于它们自己的存储库中，不会被分支(git-submodule，我最近了解到了它)。这样的话，所有的分支都有所有的迁移。棘手的部分是确保每个分支仅限于它们关心的迁移。手动进行/保持跟踪将是一种pita，并且容易出错。但是没有一个迁移工具是为此而构建的。这就是我没有前进方向的地方。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3210183|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I totally experience the pita you are having here. As I think about it, the real issue is that all the branches don't have the code to rollback certain branches. I'm in the django world, so I don't know rake that well. I'm toying with the idea that the migrations live in their own repo that doesn't get branched (git-submodule, which I recently learned about). That way all the branches have all the migrations. The sticky part is making sure each branch is restricted to only the migrations they care about. Doing/keeping track of that manually would be a pita and prone to error. But none of the migration tools are built for this. That is the point at which I am without a way forward.

blocks|key|2997004|text|也许您应该将此视为您的开发数据库太大的提示？如果您可以使用db/seeds.rb和较小的数据集进行开发，那么您的问题可以通过使用当前分支中的schema.rb和seeds.rb轻松解决。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2997005|这假设您的问题与开发有关；我无法想象为什么您需要在生产环境中定期切换分支。|2997006|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Perhaps you should take this as a hint that your development database is too big? If you can use db/seeds.rb and a smaller data set for development then your issue can be easily solved by using schema.rb and seeds.rb from the current branch.

That assumes that your question relates to development; I can't imagine why you'd need to regularly switch branches in production.

blocks|key|285047|text|我也在为同样的问题苦苦挣扎。以下是我的解决方案：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|285048|developers.|285049|There+|unordered-list-item|285050|确保所有schema.rb和所有迁移都由一个人/一台机器签入，以便部署到生产环境。让我们将这台机器称为合并机器。将更改拉入合并机时，schema.rb的自动合并将失败。没有问题。只需将内容替换为schema.rb之前的内容(您可以将副本放在一边或从github获取，如果您使用它...)。|ordered-list-item|285051|在这里是重要的一步。来自所有开发人员的迁移现在将在db/migrate文件夹中可用。继续运行bundle+exec+rake+db:migrate。它将使合并机上的数据库与所有更改保持一致。它还将重新生成schema.rb。|285052|将更改提交并推送到所有存储库(远程和个人，这也是远程)。你应该做完了！|285053|285054|285055|entityMap^0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|T|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|U|8|@]|9|@]|A|$]]|$1|J|3|K|5|I|7|V|8|@]|9|@]|A|$]]|$1|L|3|M|5|I|7|W|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|P|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|Q|$]]

I was struggling with the same issue. Here is my solution:

<ol>
<li>Make sure that both schema.rb and all migrations are checked in by all developers.</li>
<li>There should be one person/machine for deployments to production. Let's call this machine as the merge-machine. When the changes are pulled to the merge machine, the auto-merge for schema.rb will fail. No issues. Just replace the content with whatever the previous contents for schema.rb was (you can put a copy aside or get it from github if you use it ...).</li>
<li>Here is the important step. The migrations from all developers will now be available in db/migrate folder. Go ahead and run bundle exec rake db:migrate. It will bring the database on the merge machine at par with all changes. It will also regenerate schema.rb. </li>
<li>Commit and push the changes out to all repositories (remotes and individuals, which are remotes too). You should be done!</li>
</ol>

blocks|key|281714|text|下面是我编写的一个脚本，用于在包含不同迁移的分支之间进行切换：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|281715|https://gist.github.com/4076864|offset|length|281716|它不会解决你提到的所有问题，但给出一个分支名称，它会：|281717|281718|回滚当前分支上不存在于给定分支上的任何迁移|ordered-list-item|281719|放弃对db/schema.rb文件的任何更改|281720|签出给定分支|281721|运行给定分支中存在的任何新迁移|281722|<代码>H110更新测试数据库<代码>H211<代码>G212|281723|我发现我自己在我们的项目中一直在手动做这件事，所以我想自动化这个过程会很好。|281724|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|V|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@$D|14|E|15|1|16]]|A|$]]|$1|F|3|G|5|6|7|17|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|18|8|@]|9|@]|A|$]]|$1|I|3|J|5|K|7|19|8|@]|9|@]|A|$]]|$1|L|3|M|5|K|7|1A|8|@]|9|@]|A|$]]|$1|N|3|O|5|K|7|1B|8|@]|9|@]|A|$]]|$1|P|3|Q|5|K|7|1C|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1E|8|@]|9|@]|A|$]]|$1|V|3|-4|5|6|7|1F|8|@]|9|@]|A|$]]]|W|$X|$5|Y|Z|10|A|$11|C]]]]

Here's a script I wrote for switching between branches that contain different migrations:

<a href="https://gist.github.com/4076864">https://gist.github.com/4076864</a>

It won't solve all the problems you mentioned, but given a branch name it will:

<ol>
<li>Roll back any migrations on your current branch which do not exist on the given branch</li>
<li>Discard any changes to the db/schema.rb file</li>
<li>Check out the given branch</li>
<li>Run any new migrations existing in the given branch</li>
<li>Update your test database</li>
</ol>

I find myself manually doing this all the time on our project, so I thought it'd be nice to automate the process.

blocks|key|2997205|text|这就是我所做的，我不是很确定我已经涵盖了所有的基础：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2997206|在开发中(使用postgresql)：|2997207|分支分支sql_dump+db_name+>+tmp/branch1.sql|2997208|git+|unordered-list-item|2997209|
|2997210|sql_dump+db_name+branch2|2997211|2997212|dropdb+db_name+|2997213|2997214|createdb+db_name+|2997215|2997216|psql+db_name2.sql#(来自上一个分支交换机)|2997217|
<代码>F211|2997218|这比在具有大约50K记录的数据库上使用rake实用程序要快得多。|2997219|对于生产环境，将主分支保持为神圣不可侵犯，并且所有迁移都已签入，shema.rb已正确合并。完成您的标准升级过程。|2997220|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|13|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|14|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|15|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|16|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|17|8|@]|9|@]|A|$]]|$1|K|3|L|5|H|7|18|8|@]|9|@]|A|$]]|$1|M|3|J|5|6|7|19|8|@]|9|@]|A|$]]|$1|N|3|O|5|H|7|1A|8|@]|9|@]|A|$]]|$1|P|3|J|5|6|7|1B|8|@]|9|@]|A|$]]|$1|Q|3|R|5|H|7|1C|8|@]|9|@]|A|$]]|$1|S|3|J|5|6|7|1D|8|@]|9|@]|A|$]]|$1|T|3|U|5|H|7|1E|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1F|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1G|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1H|8|@]|9|@]|A|$]]|$1|11|3|-4|5|6|7|1I|8|@]|9|@]|A|$]]]|12|$]]

This is what I have done and I'm not quite sure that I have covered all the bases:

In development (using postgresql):

<ul>
<li>sql_dump db_name > tmp/branch1.sql</li>
<li>git checkout branch2</li>
<li>dropdb db_name </li>
<li>createdb db_name </li>
<li>psql db_name &lt; tmp/branch2.sql # (from previous branch switch)</li>
</ul>

This is a lot faster than the rake utilities on a database with about 50K records.

For production, maintain the master branch as sacrosanct and all migrations are checked in, shema.rb properly merged. Go through your standard upgrade procedure.

blocks|key|3210501|text|关于开发环境：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3210502|您应该使用rake+db:migrate:redo来测试您的脚本是否可逆，但请记住，应该始终使用一个包含数据填充的seed.rb。|offset|length|style|CODE|3210503|如果你使用git，你seed.rb应该随着迁移的改变而改变，并且开始执行db:migrate:redo+(为在其他机器或新数据库上的新开发加载数据)|3210504|除了"change“之外，你的up和down的方法，你的代码总是在这个时刻和从零开始时覆盖”change“的场景。|3210505|entityMap^0|0|5|K|1L|7|0|10|F|0|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|O|8|@$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]]|9|@]|A|$]]|$1|J|3|K|5|6|7|W|8|@]|9|@]|A|$]]|$1|L|3|-4|5|6|7|X|8|@]|9|@]|A|$]]]|M|$]]

On development environment:

You should work with <code>rake db:migrate:redo</code> to test if your script are reversible, but keep in mind always should have a <code>seed.rb</code> with the data population.

If you work with git, you seed.rb should be change with an migration change, and the execution of <code>db:migrate:redo</code> for the begining (load the data for a new development on other machine or new database)

Apart of ´change´, with yours up's and down's methods your code always be cover scenarios for the "change" in this moment and when start from zero.

blocks|key|285305|text|每个分支机构的单独数据库|type|unstyled|depth|inlineStyleRanges|entityRanges|data|285306|这是唯一能飞的方法。|285307|更新:+2017年10月16日|285308|在相当长的一段时间后，我又回到了这里，并做了一些改进：|285309|随着bundle+exec+rake+git:branch.|offset|length|style|CODE|285310|I意识到从克隆并不总是您想要的操作，我添加了另一个命名空间|unordered-list-item|285311|任务来一举创建分支并克隆数据库，所以我更明确地说明了db:clone_from_branch任务需要一个SOURCE_BRANCH和一个TARGET_BRANCH环境变量。在使用SOURCE_BRANCH.|285312|Refactoring和simplification.|285313|时，它将自动使用当前分支作为git:branch|285314|285315|config/database.yml|285316|为了方便起见，下面是如何更新database.yml文件以根据当前分支动态确定数据库名称的方法。|285317|<%25+
database_prefix+=+'your_app_name'
environments++++=+%25W(+development+test+)+
current_branch++=+`git+status+%7C+head+-1`.to_s.gsub('On+branch+','').chomp
%25>

defaults:+&defaults
++pool:+5
++adapter:+mysql2
++encoding:+utf8
++reconnect:+false
++username:+root
++password:
++host:+localhost

<%25+environments.each+do+%7Cenvironment%7C+%25>++

<%25=+environment+%25>:
++<<:+*defaults
++database:+<%25=+[+database_prefix,+current_branch,+environment+].join('_')+%25>
<%25+end+%25>|code-block|syntax|javascript|285318|lib/tasks/db.rake|285319|这里有一个Rake任务，可以轻松地将数据库从一个分支克隆到另一个分支。这需要一个SOURCE_BRANCH和一个TARGET_BRANCH环境变量。基于@spalladino的任务。|285320|namespace+:db+do

++desc+"Clones+database+from+another+branch+as+specified+by+`SOURCE_BRANCH`+and+`TARGET_BRANCH`+env+params."
++task+:clone_from_branch+do

++++abort+"You+need+to+provide+a+SOURCE_BRANCH+to+clone+from+as+an+environment+variable."+if+ENV['SOURCE_BRANCH'].blank?
++++abort+"You+need+to+provide+a+TARGET_BRANCH+to+clone+to+as+an+environment+variable."+++if+ENV['TARGET_BRANCH'].blank?

++++database_configuration+=+Rails.configuration.database_configuration[Rails.env]
++++current_database_name+=+database_configuration["database"]

++++source_db+=+current_database_name.sub(CURRENT_BRANCH,+ENV['SOURCE_BRANCH'])
++++target_db+=+current_database_name.sub(CURRENT_BRANCH,+ENV['TARGET_BRANCH'])

++++mysql_opts+=++"-u+#{database_configuration['username']}+"
++++mysql_opts+<<+"--password=\"#{database_configuration['password']}\"+"+if+database_configuration['password'].presence

++++`mysqlshow+#{mysql_opts}+%7C+grep+"#{source_db}"`
++++raise+"Source+database+#{source_db}+not+found"+if+$?.to_i+!=+0

++++`mysqlshow+#{mysql_opts}+%7C+grep+"#{target_db}"`
++++raise+"Target+database+#{target_db}+already+exists"+if+$?.to_i+==+0

++++puts+"Creating+empty+database+#{target_db}"
++++`mysql+#{mysql_opts}+-e+"CREATE+DATABASE+#{target_db}"`

++++puts+"Copying+#{source_db}+into+#{target_db}"
++++`mysqldump+#{mysql_opts}+#{source_db}+%7C+mysql+#{mysql_opts}+#{target_db}`

++end

end|285321|lib/tasks/git.rake|285322|此任务将在当前分支(主分支或其他分支)的基础上创建一个git分支，将其签出并将当前分支的数据库克隆到新分支的数据库中。这是圆滑的AF。|285323|namespace+:git+do

++desc+"Create+a+branch+off+the+current+branch+and+clone+the+current+branch's+database."
++task+:branch+do+
++++print+'New+Branch+Name:+'
++++new_branch_name+=+STDIN.gets.strip+

++++CURRENT_BRANCH+=+`git+status+%7C+head+-1`.to_s.gsub('On+branch+','').chomp

++++say+"Creating+new+branch+and+checking+it+out..."
++++sh+"git+co+-b+#{new_branch_name}"

++++say+"Cloning+database+from+#{CURRENT_BRANCH}..."

++++ENV['SOURCE_BRANCH']+=+CURRENT_BRANCH+#+Set+source+to+be+the+current+branch+for+clone_from_branch+task.
++++ENV['TARGET_BRANCH']+=+new_branch_name
++++Rake::Task['db:clone_from_branch'].invoke

++++say+"All+done!"
++end

end|285324|现在，您需要做的就是运行bundle+exec+git:branch，输入新的分支名称并开始杀死僵尸。|285325|entityMap|0|LINK|mutability|MUTABLE|url|https://gist.github.com/spalladino/c8c51f12d1957a8b7de0^0|0|0|0|0|2|R|0|0|Q|K|1G|D|1W|D|2H|D|0|0|E|A|0|0|0|J|0|E|C|0|0|0|H|0|14|D|1K|D|24|B|0|0|0|0|I|0|0|0|C|M|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1V|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1W|8|@$J|1X|K|1Y|L|M]]|9|@]|A|$]]|$1|N|3|O|5|P|7|1Z|8|@]|9|@]|A|$]]|$1|Q|3|R|5|P|7|20|8|@$J|21|K|22|L|M]|$J|23|K|24|L|M]|$J|25|K|26|L|M]|$J|27|K|28|L|M]]|9|@]|A|$]]|$1|S|3|T|5|P|7|29|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|2A|8|@$J|2B|K|2C|L|M]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|2D|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|2E|8|@$J|2F|K|2G|L|M]]|9|@]|A|$]]|$1|Z|3|10|5|6|7|2H|8|@$J|2I|K|2J|L|M]]|9|@]|A|$]]|$1|11|3|12|5|13|7|2K|8|@]|9|@]|A|$14|15]]|$1|16|3|17|5|6|7|2L|8|@$J|2M|K|2N|L|M]]|9|@]|A|$]]|$1|18|3|19|5|6|7|2O|8|@$J|2P|K|2Q|L|M]|$J|2R|K|2S|L|M]]|9|@$J|2T|K|2U|1|2V]]|A|$]]|$1|1A|3|1B|5|13|7|2W|8|@]|9|@]|A|$14|15]]|$1|1C|3|1D|5|6|7|2X|8|@$J|2Y|K|2Z|L|M]]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|30|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|13|7|31|8|@]|9|@]|A|$14|15]]|$1|1I|3|1J|5|6|7|32|8|@$J|33|K|34|L|M]]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|35|8|@]|9|@]|A|$]]]|1L|$1M|$5|1N|1O|1P|A|$1Q|1R]]]]

<h1>Separate Database for each Branch</h1>

It's the only way to fly.

<h3>Update October 16th, 2017</h3>

I returned to this after quite some time and made some improvements:

<ul>
<li>I've added another namespace rake task to create a branch and clone the database in one fell swoop, with <code>bundle exec rake git:branch</code>.</li>
<li>I realize now that cloning from master is not always what you want to do so I made it more explicit that the <code>db:clone_from_branch</code> task takes a <code>SOURCE_BRANCH</code> and a <code>TARGET_BRANCH</code> environment variable. When using <code>git:branch</code> it will automatically use the current branch as the <code>SOURCE_BRANCH</code>.</li>
<li>Refactoring and simplification.</li>
</ul>

<h2><code>config/database.yml</code></h2>

And to make it easier on you, here's how you update your <code>database.yml</code> file to dynamically determine the database name based on the current branch.

<pre><code>&lt;% 
database_prefix = 'your_app_name'
environments = %W( development test ) 
current_branch = `git status | head -1`.to_s.gsub('On branch ','').chomp
%&gt;

defaults: &amp;defaults
 pool: 5
 adapter: mysql2
 encoding: utf8
 reconnect: false
 username: root
 password:
 host: localhost

&lt;% environments.each do |environment| %&gt; 

&lt;%= environment %&gt;:
 &lt;&lt;: *defaults
 database: &lt;%= [ database_prefix, current_branch, environment ].join('_') %&gt;
&lt;% end %&gt;
</code></pre>

<h2><code>lib/tasks/db.rake</code></h2>

Here's a Rake task to easily clone your database from one branch to another. This takes a <code>SOURCE_BRANCH</code> and a <code>TARGET_BRANCH</code> environment variables. Based off of <a href="https://gist.github.com/spalladino/c8c51f12d1957a8b7de0" rel="noreferrer">@spalladino</a>'s task.

<pre><code>namespace :db do

 desc "Clones database from another branch as specified by `SOURCE_BRANCH` and `TARGET_BRANCH` env params."
 task :clone_from_branch do

 abort "You need to provide a SOURCE_BRANCH to clone from as an environment variable." if ENV['SOURCE_BRANCH'].blank?
 abort "You need to provide a TARGET_BRANCH to clone to as an environment variable." if ENV['TARGET_BRANCH'].blank?

 database_configuration = Rails.configuration.database_configuration[Rails.env]
 current_database_name = database_configuration["database"]

 source_db = current_database_name.sub(CURRENT_BRANCH, ENV['SOURCE_BRANCH'])
 target_db = current_database_name.sub(CURRENT_BRANCH, ENV['TARGET_BRANCH'])

 mysql_opts = "-u #{database_configuration['username']} "
 mysql_opts &lt;&lt; "--password=\"#{database_configuration['password']}\" " if database_configuration['password'].presence

 `mysqlshow #{mysql_opts} | grep "#{source_db}"`
 raise "Source database #{source_db} not found" if $?.to_i != 0

 `mysqlshow #{mysql_opts} | grep "#{target_db}"`
 raise "Target database #{target_db} already exists" if $?.to_i == 0

 puts "Creating empty database #{target_db}"
 `mysql #{mysql_opts} -e "CREATE DATABASE #{target_db}"`

 puts "Copying #{source_db} into #{target_db}"
 `mysqldump #{mysql_opts} #{source_db} | mysql #{mysql_opts} #{target_db}`

 end

end
</code></pre>

<h2><code>lib/tasks/git.rake</code></h2>

This task will create a git branch off of the current branch (master, or otherwise), check it out and clone the current branch's database into the new branch's database. It's slick AF.

<pre><code>namespace :git do

 desc "Create a branch off the current branch and clone the current branch's database."
 task :branch do 
 print 'New Branch Name: '
 new_branch_name = STDIN.gets.strip 

 CURRENT_BRANCH = `git status | head -1`.to_s.gsub('On branch ','').chomp

 say "Creating new branch and checking it out..."
 sh "git co -b #{new_branch_name}"

 say "Cloning database from #{CURRENT_BRANCH}..."

 ENV['SOURCE_BRANCH'] = CURRENT_BRANCH # Set source to be the current branch for clone_from_branch task.
 ENV['TARGET_BRANCH'] = new_branch_name
 Rake::Task['db:clone_from_branch'].invoke

 say "All done!"
 end

end
</code></pre>

Now, all you need to do is run <code>bundle exec git:branch</code>, enter in the new branch name and start killing zombies.

blocks|key|2997545|text|我建议使用以下两个选项之一：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2997546|选项1|2997547|2997548|将您的数据放入seeds.rb。一个很好的选择是通过FactoryGirl/Fabrication+gem创建种子数据。这样，如果我们假设工厂随列的添加/删除一起更新，则可以保证数据与代码同步。|ordered-list-item|offset|length|style|CODE|2997549|从一个分支切换到另一个分支后，运行rake+db:reset，这将有效地删除/创建/播种数据库。|2997550|2997551|选项2|2997552|通过在分支结帐之前/之后始终运行rake+db:rollback/rake+db:migrate来手动维护数据库的状态。需要注意的是，您的所有迁移都必须是可逆的，否则将无法正常工作。|2997553|entityMap^0|0|0|0|7|8|0|H|D|0|0|0|G|G|X|F|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|V|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|W|8|@]|9|@]|A|$]]|$1|E|3|F|5|G|7|X|8|@$H|Y|I|Z|J|K]]|9|@]|A|$]]|$1|L|3|M|5|G|7|10|8|@$H|11|I|12|J|K]]|9|@]|A|$]]|$1|N|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|15|8|@$H|16|I|17|J|K]|$H|18|I|19|J|K]]|9|@]|A|$]]|$1|S|3|-4|5|6|7|1A|8|@]|9|@]|A|$]]]|T|$]]

I would suggest one of two options:

<h3>Option 1</h3>

<ol>
<li>Put your data in <code>seeds.rb</code>. A nice option is to create your seed data via FactoryGirl/Fabrication gem. This way you can guarantee that the data is in sync with the code if we assume, that the factories are updated together with the addition/removal of columns.</li>
<li>After switching from one branch to another, run <code>rake db:reset</code>, which effectively drops/creates/seeds the database.</li>
</ol>

<h3>Option 2</h3>

Manually maintain the states of the database by always running <code>rake db:rollback</code>/<code>rake db:migrate</code> before/after a branch checkout. The caveat is that all your migrations need to be reversible, otherwise this won't work.

blocks|key|3210872|text|如果执行git提取，您应该已经拥有最新的模式，受通过提取传入的任何迁移的影响，但是您的数据库表可能不会更新。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3210873|因此，您确实需要在拉入之后运行迁移，但这通常会更改db/schema.rb|3210874|如果您所做的只是拉入和迁移，那么您没有理由提交任何由此产生的模式更改，因为从技术上讲，它们不属于您，并且它们可能最终是无关的/不正确的|3210875|重置模式差异最有意义|3210876|下面是创建新分支之前要做的事情的逐步版本|3210877|3210878|切换到您的父/基分支|unordered-list-item|3210879|提取最新代码|3210880|运行包exec+schema.rb+db：以本地更新|3210881|文件|3210882|执行一个db:migrate|3210883|Create签出db/schema.rb以丢弃迁移新分支带来的更改并切换到该分支<代码>H111确保在切换到另一个分支之前提交您的更改<代码>H212<代码>F213|3210884|3210885|3210886|改编自here|offset|length|3210887|entityMap|0|LINK|mutability|MUTABLE|url|https://fuzzyblog.io/blog/rails/2019/05/09/rails-migrations-multiple-developers-and-the-schema-wtf-moment.html^0|0|0|0|0|0|0|0|0|1|1|1|1|0|0|3|4|0|0^^$0|@$1|2|3|4|5|6|7|1B|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1C|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1D|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1E|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1F|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|1G|8|@]|9|@]|A|$]]|$1|K|3|L|5|M|7|1H|8|@]|9|@]|A|$]]|$1|N|3|O|5|M|7|1I|8|@]|9|@]|A|$]]|$1|P|3|Q|5|M|7|1J|8|@]|9|@]|A|$]]|$1|R|3|S|5|M|7|1K|8|@]|9|@]|A|$]]|$1|T|3|U|5|M|7|1L|8|@]|9|@]|A|$]]|$1|V|3|W|5|M|7|1M|8|@]|9|@]|A|$]]|$1|X|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|Y|3|-4|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1P|8|@]|9|@$11|1Q|12|1R|1|1S]]|A|$]]|$1|13|3|-4|5|6|7|1T|8|@]|9|@]|A|$]]]|14|$15|$5|16|17|18|A|$19|1A]]]]

If you do a git pull, you should already have the latest schema, affected by any migrations that came in via the pull, but your database tables may not be updated
So, you do need to run the migrations after pulling, but this will often change db/schema.rb
If all you've done is pull and migrate, there's no reason you should be responsible for committing any of the resultant schema changes as they don't technically belong to you, and they may end up being extraneous/incorrect
Resetting the schema diff makes the most sense
Here is my step by step version of what to do before creating a new branch
<ul>
<li>Switch to your parent/base branch</li>
<li>Pull the latest code</li>
<li>Run bundle exec rake db:migrate to update your schema.rb file locally</li>
<li>Do a git checkout db/schema.rb to throw away the changes brought by db:migrate</li>
<li>Create your new branch and switch to it</li>
<li>Make sure to commit your changes before switching to another branch</li>
</ul>
Adapted from <a href="https://fuzzyblog.io/blog/rails/2019/05/09/rails-migrations-multiple-developers-and-the-schema-wtf-moment.html" rel="nofollow noreferrer">here</a>

I am working on a rails app with quite a few git branches and many of them include db migrations. We try to be careful but occasionally some piece of code in master asks for a column that got removed/renamed in another branch.
<ol>
<li>What would be a nice solution to &quot;couple&quot; git branches with DB states?
</li>
<li>What would these &quot;states&quot; actually be?
We can't just duplicate a database if it's a few GBs in size.
</li>
<li>And what should happen with merges?
</li>
<li>Would the solution translate to noSQL databases as well?
We currently use MySQL, mongodb and redis
</li>
</ol>
<hr />
EDIT: Looks like I forgot to mention a very important point, I am only interested in the development environment but with large databases (a few GBs in size).

How to work with Git branches and Rails migrations

SQL数据库

数据库

MySQL

我正在开发一个带有相当多git分支的rails应用程序，其中许多分支都包含数据库迁移。我们尽量小心，但偶尔master中的一些代码会请求在另一个分支中删除/重命名的列。将git分支与DB states?“耦合”起来，What将是一个很好的解决方案这些“状态”真的会是吗？如果数据库的大小只有几GB，我们就不能简单地复制它...

问如何使用Git分支和Rails迁移
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用Git分支和Rails迁移EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问如何使用Git分支和Rails迁移
EN