Hi mates, i am working with my team ( we are 4 in total) on a django project and any developer could make a modification on a model and then genera...
For further actions, you may consider blocking this person and/or reporting abuse
I have run into this problem in the past and one strategy we have used is reset the migrations after each release. It has helped us keep the migration folder small, and it's bit easier to see the conflicting changes. I do think during development cycles if you isolate your applications and models per developer you eliminate almost entirely the conflicts from migrations if combined with a reset after release.
Your issue is communication, not source control :-) You should probably consider using another branching strategy and if a feature requires changing the DB you should communicate it to the others, especially because you're 4, not 45.
This is a good guide on how to manage conflicts: algotech.solutions/blog/python/dja...
You can merge migrations or just squash them to a single file.
You obviously need the migrations in the source control, otherwise you won't be able to reproduce the schema from start or to create the next migration building on the previous one.
In the framework me and my team are using, we use 1 migration = 1 table strategy.
Every time we pull a modified migration, we just run a script to automatically re-import and repopulate the database. Hope this helps.
A VCS is too much effort in 9 out of 10 real life cases IMO.
Care to explain why?
Because it adds complexity and maintenance cost to your workflow.
like in my case.