Ho intenzione di spiegare la mia domanda con un esempio concreto in cui questa domanda è saltata fuori:
Sto lavorando a un progetto Django di grandi dimensioni con poche persone. Django crea automaticamente piani di migrazione e li salva in file separati quando il modello del database viene modificato. Le modifiche al modello possono essere applicate su rami diversi in parallelo. Django supporta effettivamente questo con l'introduzione delle migrazioni unire .
In sostanza, dopo la fusione di rami con modifiche divergenti al modello, si crea un altro piano di migrazione che fa riferimento a tutte le foglie nel grafico dei piani di migrazione (paragonabile al modo in cui Git rappresenta le unioni).
Ora la mia domanda è questa: sulla base del fatto che dopo aver unito le filiali senza aggiungere la migrazione di unione, il progetto non è rotto di per sé (una configurazione esistente continua a essere eseguita), ma non è nemmeno in o uno stato molto buono (non è possibile applicare le migrazioni a un database o inizializzarne uno nuovo), dovrei includere la migrazione di unione nello stesso commit o dovrei aggiungerlo in un commit separato? Quali sono le implicazioni di farlo in un modo o nell'altro?
La mia domanda riguarda il caso generale in cui un'unione introduce incoerenze, non rompendo il codice stesso (ovvero rinominando un metodo in cui è stato introdotto un altro utilizzo nell'altro ramo), ma a un livello superiore, che potrebbe includere documentazione incoerente o dati ausiliari rotti (dati di test e script, script di installazione, file di impostazioni predefinite).