Maybe this has been asked, but, at least from the ones i've readed, i'm not convinced. The idea is that i'm on a project with multiple people working on the backend, and because people are assigned to solve different issues, each one make their own changes on the models, and that implies each one can have their own migrations, which might clash either by just having the same numbered migration as to make changes to the same tables.
As a way to work with this, we devised a solution in which we create 3 branches: Master, QA and Develop, the first one is the one at production, Develop is the one where changes to test on our development server will be merged to test, and QA as an intermediate between the 2, the idea is that we will be working the changes on new branches(feature/xxxxxx) with their respective migrations, and when we need to upload to the developmente server, we will merge to develop, which will handle migration conflicts(manage.py makemigrations --merge), and then, when the change is approved, we will delete the migrations of the new branch(feature/xxxxxx), merge it to QA, and delete that branch, and once QA is ready to be uploaded to production, we run the Makemigration to create the migrations, and that is what we merge to Master.
My problem here is the divergence that would be between develop and QA, since the idea is that everything in QA should work the same as how it worked on Develop, but since Develop will handle the migrations merging them, while QA will create them from zero, i'm not sure if something could work differently because of that, also, merging Develop with QA is not an answer, since the point of this structure is that Develop can have features that are still being worked on, and are not approved to be uploaded, so we don't want them to make Production unstable.
Is there a better way to handle this, or a way to improve this method?