You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Check out my book `Speed Up Your Django Tests <https://gumroad.com/l/suydt>`__ which covers loads of best practices so you can write faster, more accurate tests.
31
+
32
+
----
33
+
34
+
Installation
35
+
============
36
+
37
+
First, install with **pip**:
38
+
39
+
.. code-block:: bash
40
+
41
+
python -m pip install django-migration-conflicts
42
+
43
+
Second, add the app to your ``INSTALLED_APPS`` setting:
44
+
45
+
.. code-block:: python
46
+
47
+
INSTALLED_APPS= [
48
+
...
49
+
"django_migration_conflicts",
50
+
...
51
+
]
52
+
53
+
The app relies on overriding the built-in ``makemigrations`` command.
54
+
If your project has a custom ``makemigrations`` command, ensure the app containing your custom command is **above** ``django_migration_conflicts``, and that your command subclasses its ``Command`` class:
55
+
56
+
.. code-block:: python
57
+
58
+
# myapp/management/commands/makemigrations.py
59
+
from django_migration_conflicts.management.commands.makemigrations import (
This extra subcommand creates a new ``max_migration.txt`` file in each of your apps’ ``migrations`` directories and exits.
74
+
More on that file below...
75
+
76
+
Usage
77
+
=====
78
+
79
+
django-migration-conflicts helps you work on Django projects where several branches adding migrations may be in progress at any time.
80
+
It enforces the use of a *linear* migration history, avoiding merge migrations and any possible problems from migrations running in different orders.
81
+
It does this by turning parallel migration development into conflicts on per-app ``max_migration.txt`` files that your source control tool (Git, Mercurial, etc.) will detect.
82
+
83
+
Its extended ``makemigrations`` command updates the ``max_migration.txt`` file with the name of the new migration when run.
84
+
85
+
System Checks
86
+
=============
87
+
88
+
django-migration-conflicts comes with several system checks that verify that your ``max_migration.txt`` files are in sync.
89
+
These are:
90
+
91
+
* ``dmc.E001``: ``<app_label>``'s max_migration.txt does not exist.
* ``dmc.E003``: ``<app_label>``'s max_migration.txt points to non-existent migration '``<bad_migration_name>``'.
94
+
* ``dmc.E004``: ``<app_label>``'s max_migration.txt contains '``<max_migration_name>``', but the latest migration is '``<real_max_migration_name>``'.
95
+
96
+
Limitations
97
+
===========
98
+
99
+
This only works with ``.py`` migration files.
100
+
101
+
Inspiration
102
+
===========
103
+
104
+
I've seen versions of this technique implemented at my previous client `Pollen <https://pollen.co/>`__ and in `this Doordash blogpost <https://medium.com/@DoorDash/tips-for-building-high-quality-django-apps-at-scale-a5a25917b2b5>`__, and have ended up implementing it myself a couple of times.
105
+
There's also `django-migrations-git-conflicts <https://pypi.org/project/django-migrations-git-conflicts/>`__ which does similar.
0 commit comments