git alembic 修订版 - 多头（由于分支）错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/22342643/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
alembic revision - multiple heads (due branching) error
提问by Arek S
I've got an application and I wanted to create a new migration for it today. When I run
我有一个应用程序，我今天想为它创建一个新的迁移。当我跑
$ alembic revision -m "__name__"
I got a message
我收到一条消息
Only a single head is supported. The script directory has multiple heads (due branching), which must be resolved by manually editing the revision files to form a linear sequence.
Run `alembic branches` to see the divergence(s).
Running
跑步
alembic branches
gives nothing
什么都不给
I'm new to alembic. There are 2 developers working on this app and we have 2 git branches - master & develop (I'm not sure if this have anything to do with it).
我是 Alembic 的新手。有 2 个开发人员在开发这个应用程序，我们有 2 个 git 分支 - master & develop（我不确定这是否与它有关）。
Any clue on what is this about?
这是关于什么的任何线索？
采纳答案by Arek S
I've run
我跑了
$ python manage.py db history
And as a result I got
结果我得到了
vagrant@precise64:/vagrant$ python manage.py db history
Rev: 29c319804087 (head)
Parent: 313837798149
Path: migrations/versions/29c319804087_.py
empty message
Revision ID: 29c319804087
Revises: 313837798149
Create Date: 2014-03-05 21:26:32.538027
Rev: 313837798149
Parent: 280061454d2a
Path: migrations/versions/313837798149_.py
empty message
Revision ID: 313837798149
Revises: 280061454d2a
Create Date: 2014-01-10 03:19:39.838932
Rev: 280061454d2a
Parent: None
Path: migrations/versions/280061454d2a_.py
empty message
Revision ID: 280061454d2a
Revises: None
Create Date: 2013-12-08 03:04:55.885033
Rev: 2e74f61d3b80 (head)
Parent: 49501407aec9
Path: migrations/versions/2e74f61d3b80_o2_lease.py
o2 lease
Revision ID: 2e74f61d3b80
Revises: 49501407aec9
Create Date: 2014-02-28 10:38:06.187420
Rev: 49501407aec9
Parent: None
Path: migrations/versions/49501407aec9_.py
empty message
Revision ID: 49501407aec9
Revises: None
Create Date: 2014-01-22 11:27:08.002187
What you can see here is 2 different branches. One starts from 49501407aec9 and second from 280061454d2a. I moved 49501407aec9 and the following 2e74f61d3b80 out of the /versions directory, run
您可以在这里看到 2 个不同的分支。第一个从 49501407aec9 开始，第二个从 280061454d2a 开始。我将 49501407aec9 和以下 2e74f61d3b80 移出 /versions 目录，运行
$ python manage.py db revision
and it created a new migration file.
并创建了一个新的迁移文件。
回答by Mark Amery
Perhaps the most conventional (and robust) solution is to use alembic merge heads. In the same way that when you have two branches in Git you can bring them back together with a merge commit, in Alembic when you have two branches you can bring them back together with a merge revision.
也许最传统（和稳健）的解决方案是使用alembic merge heads. 就像在 Git 中有两个分支时，您可以通过合并提交将它们重新组合在一起，在 Alembic 中，当您有两个分支时，您可以通过合并修订将它们重新组合在一起。
For instance, suppose we have a revision 1a6b1a4a0574 that adds table A, and a revision 2e49118db057 that adds table B. We can see these revisions (both marked as (head)) in alembic history:
例如，假设我们有一个添加表 A 的修订版 1a6b1a4a0574 和添加表 B 的修订版 2e49118db057。我们可以在以下位置看到这些修订版（都标记为(head)）alembic history：
$ alembic history
<base> -> 2e49118db057 (head), Add table B
<base> -> 1a6b1a4a0574 (head), Add table A
Then we can merge them by running alembic merge heads:
然后我们可以通过运行合并它们alembic merge heads：
$ alembic merge heads
Generating /Users/markamery/alembictest/alembic/versions/409782f4c459_.py ... done
$ alembic history
2e49118db057, 1a6b1a4a0574 -> 409782f4c459 (head) (mergepoint), empty message
<base> -> 2e49118db057, Add table B
<base> -> 1a6b1a4a0574, Add table A
If one of your revisions may have already been run somewhere (including on the development machine of one of your coworkers), then you probably want to use alembic mergeinstead of tinkering with the down_revisionof one of the revisions, as the other answers here suggest. The danger of tinkering with the down revision is that it may result in a revision never getting applied. For instance, suppose that your colleague Bob has already pulled down your branch with revision 2e49118db057 and run alembic upgrade head, creating table B. Then you decide to modify the down_revisionof 2e49118db057 to point to 1a6b1a4a0574, which Bob has never seen or run before. Bob pulls down your change, runs alembic upgrade head, and... nothing happens, because as far as Alembic is concerned he's already at the headand doesn't need to run 1a6b1a4a0574. And so Bob ends up never getting table A and probably never figures out why his database is in a broken state.
如果您的一个修订版本可能已经在某处运行（包括在您一位同事的开发机器上），那么您可能想要使用alembic merge而不是修改其中down_revision一个修订版本的 ，正如这里的其他答案所建议的那样。修补向下修订的危险在于它可能导致永远不会应用修订。例如，假设您的同事 Bob 已经删除了修订版为 2e49118db057 的分支并运行alembic upgrade head，创建表 B。然后您决定修改down_revision2e49118db057 的 指向 1a6b1a4a0574，这是 Bob 以前从未见过或运行过的。鲍勃拉下你的零钱，跑了alembic upgrade head，然后……什么也没发生，因为就 Alembic 而言，他已经在head并且不需要运行 1a6b1a4a0574。所以 Bob 最终永远不会得到表 A，并且可能永远不会弄清楚为什么他的数据库处于损坏状态。
Don't break Bob's database - make a merge revision instead.
不要破坏 Bob 的数据库 - 而是进行合并修订。
回答by muzhikas
This issue happens when two alembic migrations are branched from the same migration. Usually, this happens when multiple people are making schema changes. To fix it you just have to adjust thedown_revisionof your migration to be that of the latest one. Running alembic historyshows us this:
当两个 alembic 迁移从同一个迁移分支时会发生此问题。通常，当多人进行架构更改时会发生这种情况。要修复它，您只需down_revision将迁移调整为最新的迁移。跑步alembic history向我们展示了这一点：
2f4682466279 -> f34e92e9dc54 (head), Fifth revision (on a separate branch)
2f4682466279 -> f673ac37b34a (head), Fifth revision (local)
2dc9337c3987 -> 2f4682466279, Fourth revision
0fa2aed0866a -> 2dc9337c3987, Third revision
22af4a75cf06 -> 0fa2aed0866a, Second revision
9a8942e953eb -> 22af4a75cf06, First revision
You can see that one of the Fifth revisions was made locally and it's downstream revision is2f4682466279but whoever made the other Fifth revision got the same downstream revision too.
您可以看到第五次修订中的一个是在本地进行的，它的下游修订是2f4682466279但无论谁进行了另一个第五次修订，也得到了相同的下游修订。
Go into one of the Fifth revision files and update down_revisionvariable to reference the other Fifth revision, like this:
进入第五个修订版文件之一并更新down_revision变量以引用另一个第五个修订版，如下所示：
f673ac37b34a -> f34e92e9dc54 (head), Fifth revision (on a separate branch)
2f4682466279 -> f673ac37b34a, Fifth revision (local)
2dc9337c3987 -> 2f4682466279, Fourth revision
0fa2aed0866a -> 2dc9337c3987, Third revision
22af4a75cf06 -> 0fa2aed0866a, Second revision
9a8942e953eb -> 22af4a75cf06, First revision
In this case I updated migration f34e92e9dc54to have down_revision='f673ac37b34a'.
在这种情况下，我将迁移更新f34e92e9dc54为具有down_revision='f673ac37b34a'.
