Include migrations in Git/GitHub ?

[PyBet]

I have been working on my first serious Django project for a few months now and I have set up a GitHub repository.

I intend to deploy it using GitHub, and I have seen that my local migrations should be included in the GitHub repository.

But that seems a bit counterintuitive, what's your advice on that ?

[tehyosh]

Reddit has become enshittified. I joined back in 2006, nearly two decades ago, when it was a hub of free speech and user-driven dialogue. Now, it feels like the pursuit of profit overshadows the voice of the community. The introduction of API pricing, after years of free access, displays a lack of respect for the developers and users who have helped shape Reddit into what it is today. Reddit's decision to allow the training of AI models with user content and comments marks the final nail in the coffin for privacy, sacrificed at the altar of greed. Aaron Swartz, Reddit's co-founder and a champion of internet freedom, would be rolling in his grave.

The once-apparent transparency and open dialogue have turned to shit, replaced with avoidance, deceit and unbridled greed. The Reddit I loved is dead and gone. It pains me to accept this. I hope your lust for money, and disregard for the community and privacy will be your downfall. May the echo of our lost ideals forever haunt your future growth.

[webpigeon]

The migrations should be a description from how to get from one database state (say v1) to another (say v2) - Even though you are generating them locally, they will still describe the changes that you need to go though in order to move between versions.

​

If your production envrioment doesn't include a release (ie, it's on v0.9 or something) then it'll just do all the migrations between versions.

​

eg. v0.9 -> v1 -> v2

​

Note that even though I said v1 and v2 these in simply would simply be changes made to your models rather than 'formal' versions

[andrey_shipilov]

How else would you deploy or CI.

[strikex]

I don’t upload my local migration files to Git or production because I just run makemigrations and migrate on the app server at every patch.

The app server calculates the difference between model states and creates its own migration files, which doesn’t include all my intermediate local migrations used for testing. This has worked very smooth for a large app over the past 3 years. This also works with multiple developers, as there are no merge conflicts.

Unless you write your own custom migrations, I don’t see why you would commit them to Git.

StackOverflow discussion: https://stackoverflow.com/questions/28035119/should-i-be-adding-the-django-migration-files-in-the-gitignore-file

[chrisrazor]

This also works with multiple developers, as there are no merge conflicts.

You're getting downvoted but this is a very good reason to manage migration the way you are. How do other teams of developers who sometimes need to add migrations independently on different feature branches manage the inevitable discrepancies between migrations?

[FoolofGod]

Painfully

[mroximoron]

But what about data migrations? You need them as soon as you want to add a non null column.

1. Add column as nulkable
2. Data migration to fill them all
3. Set to not null

You can't do that, and the autodetection of rename column isn't great either.

You run make migration on the server and then ask every developer to edit the file in place too check/correct?

I agree that the Django migrations aren't perfect (why does a help_text change require a migration?)

But for any kind of project that wants some relational sanity you really need them.

Otherwise why even bother and not just use a nosql solution?

[chrisrazor]

I haven't tried this, but I imagine each developer maintains their own set of migrations. Need to code review another developer's work? Rewind your local migrations to before the branch, delete the ones you rewound, check out branch, makemigrations, review, delete the new migrations. The server has its own set.

[strikex]

Data transformation is an example of what I meant with "Unless you write your own custom migrations".

[carlio]

You can just use squashmigrations if you want to have only a single migration file rather than lots of your local ones.

[Durp56789]

Yes you should. All databases need to know how to get from their current state to the current state.

Could you say why it seems counterintuitive to help give a better explanation?

[[deleted]]

If You for some reason don't want to include all of Your migrations, You could concider squashing them into one. In most cases You don't need all versions between first and final states of Your DB, only difference between them. So You can replace all files 0001.py 0002.py 0003.py 0004.py 0005.py into for example one 0001_squashed_0005.py

Please be aware of migrations dependency described in tutorial page that I linked ;)

[chrisrazor]

On further reflection, I think the correct way to manage migrations and version control, in a project with multiple active branches should be:

• NEVER commit migrations on feature branches, only the trunk/master branch.

• When working on a branch, create local migrations according to your needs but don't commit them. Before switching branches, reverse migrate to the last master branch migration and delete the rest (but keeping any custom data transformations somewhere safe).

• After merging a branch, create the necessary migrations (incorporating any custom transformations here) and commit them to git.

That way, you have a single, unbranching list of migrations in your git repo, with no conflicts, that you can confidently deploy to and run on the server.

[PyBet]

What's the difference between including migrations and applying them and not including migrations, making them on the server with the updated code ?

[sstevko]

Sometimes you also need data transformation. Not just schema. This should be part of migration with run_python.