Git configuration/management for multiple branches / configs

Using Django
1

Hi all,

I think I’ve resolved something that has been a bit of a thorn in the side of my group (of people learning software engineering and django as we go) side and wanted to check the solution makes sense, or if it should go further, or if I’m going to get myself in trouble this way. The goals are:

  1. to maintain integrity / coherence between dev branch migration history and the dev database (sqlite3) in different branches, so I can check out /switch to someone’s branch and have their database (with demo data) and their migration history.
  2. to be able to ‘pull’ to the server and be confident it won’t bring migrations files that aren’t wanted.

Basically, I follow this process for preserving local files/folders: medium: git merge driver

  1. Define a .gitattributes file (goes alongside .gitignore) (and add and commit it at the root of your development):

migrations/ merge=ours
db.sqlite3 binary
db.sqlite3 merge=ours
settings/production.py merge=ours

*The ‘binary’ line prevents git trying to ‘diff’ the database file.

  1. Define a very basic merge driver for the migrations folder and db file as per the link above (this command needs to be run on each instance of this git repository):
    git config --global merge.ours.driver true

Now, when you merge branches, you need to resolve conflicts in models.py and then make and apply migrations to your branch db, but the history of migrations and db config on your branch stay sane.

To retrofit, I need to make sure migrations and the db aren’t gitignored, and get to a ‘good’ state which we all then branch from.

Data migrations will be a weak point for this approach, because with different histories for auto-generated migrations for different branches / environments, they will need to be handcrafted to do their work in each branch / environment. Can I get a sanity check? An Amen?

2

UPDATE: DON’T RELY ON THIS.

For example, if you create a branch off main, but in that branch you delete the migrations and database and start over, git thinks that’s progress. The fact that those migrations were stable through several more commits along the “main” branch does not impress git: it will overwrite them with the changes from anyone else’s branch, REGARDLESS OF THIS MERGE STRATEGY.

So far the best alternative I have identified is a two-step>
git merge --no-ff --no-commit
git checkout [preferred commit] – /migrations/

But, even that isn’t perfect because (for reasons I don’t understand) the older migrations are often missed in this process and need to be checked out by filename. Finding the filenames is a bit of a grind in my context because we have a fairly dynamic environment with 3-7 devs developing and re-developing.