Merging ActiveRecord migrations out of order

Question

Let's say I'm working in git on my Rails app, and I have two branches, each with their own migration.

1) branch001 creates a table called tableA via migration 20160101000000_create_table_A

2) branch002 creates a table called tableB via migration 20160101000001_create_table_B

Clearly the timestamp for the 2nd migration was created after the first.

But let's say I merge branch002 to master first because it's ready first. My schema file becomes -

ActiveRecord::Schema.define(version: 20160101000001) do
  ....
end

The schema version tells activerecord it's already patched to a level/version greater than my first branch.

What will happen when I finally get around to merging my first branch?

1. Will the schema version regress to 20160101000000?
2. Will there be any issues running the first branch's migration because the schema sees it's already "patched" and skips it?
3. In general, what's the best practice for things like this? Should I rename the first branch with a new, more recent timestamp?

Thanks!

EDIT -

Really wondering what I should do to resolve the merge conflict when I merge the 2nd branch into master. Should I leave it as the later timestamp or regress it to the earlier timestamp?

<<<<<<< HEAD (master)
ActiveRecord::Schema.define(version: 20160101000001) do
=======
ActiveRecord::Schema.define(version: 20160101000000) do
>>>>>>> 282cda7... Adding Table B

Answer 1

In case of conflict you should select the higher number of the two. But whatever you choose it has no impact on actual migrations.

If you choose the lower number then next time you run rake db:migrate it will change this number (to the higher one) and you will have a change in your schema.rb and no migration. It's not a problem - only your commit will be a bit strange.

Rails rake task runs all migrations that it finds and that don't have a value in schema_migrations table. And then it takes the highest migration timestamp and puts this timestamp into the schema.rb. The whole migration idea is not based on some "most recent timestamp" (schema version) but it's based on the content of schema_migrations table that contains all migration timestamps that it has already run. So through this table it guarantees that no migration is skipped.

Answer 2

The very short version is that things are usually fine: assuming that the migrations don't interfere with each other (eg one drops a table but the other assumes it still exists) you shouldn't run into trouble.

While your schema file has a single version number in it, when you run migrations rails compares the list of migration files with the contents of the schema_migrations table and runs any migrations that have not yet been run, even if there are more recent migrations that have already been run.

As far as the schema conflict, personally I would just run the migrations, which will regenerate schema.rb.