How to integrate Alembic's non-distributable VCS with Git?

[baldurfb]

I'm trying to design a workflow for a team of developers to use Git + Alembic; which I'm sure is a common combination.
Isn't it inevitable that there will be constant conflicts when working with the Alembic revision VCS design within the very distributed Git VCS?

In an ideal world, we could hook into Github (and Bitbucket, Gitlab, etc...) so that when a PR is merged, it automatically merges the Alembic history as well. I haven't found a good way of doing this.

If we let the team run free without any guidance, something like the following happens.

1. Multiple developers make revisions and merge them onto the Git trunk without merging Alembic.
2. If the Git trunk has multiple Alembic heads, when developers pull from it they will create a merge revision on their feature branch.
3. Then, when those merge revisions enter the trunk, now there are multiple revisions merging the same two heads, with some more revisions on-top of them.
4. Then each developer solves that conflict on their own Git branch, and then that gets merged...
5. Etc..
   The Git trunk constantly has multiple Alembic heads, and every developer will need to start their branch by taming it.

If we impose the pragmatic workflow, every time a PR is merged. The developer must first pull the trunk, merge their Alembic branch with the trunk's, and only then merge the PR. This is difficult to enforce automatically, and also open to race conditions.

When googling it, we run into blog posts about people tearing alembic apart and building their own systems, just to make it team-friendly. Is that the best approach?

What is a good team workflow using Git + Alembic?

[CaselIT]

Hi,

I haven't read the blog post you linked. What I do at work is having an unit test that the number of heads is the expected one, and pr can't be merged unless they are even with the target branch. This way a PR is merged only if it does not create a new head, avoiding the issue you mentioned.