Rules Hub
Coding Rules Library
Rule priority, scope & exceptions
Use this to align rules with the senior-level structure (P0/P1/P2, scope, exceptions/tradeoffs).
Guard against colliding sequential migration numbers
Two branches can independently generate the same next migration number without the merge ever conflicting.
Bad example
| 1 | // branch A generates: migrations/0136_add_column_foo.sql |
| 2 | // branch B independently generates: migrations/0136_add_column_bar.sql |
| 3 | // merging main into either branch: no textual conflict, both files coexist |
Explanation (EN)
Because the two files have different names, git merges them cleanly even though they claim the same sequence position — the migration tool now has two "migration 0136"s, and applying them in the wrong order (or skipping the regeneration) can silently apply the wrong schema state.
Objašnjenje (HR)
Budući da datoteke imaju različita imena, git ih čisto spoji iako obje tvrde da zauzimaju istu poziciju u nizu — alat za migracije sada ima dvije 'migracije 0136', a primjena krivim redoslijedom (ili preskakanje regeneracije) može tiho primijeniti pogrešno stanje sheme.
Good example
| 1 | // before merging: rebase onto the latest base branch, then regenerate |
| 2 | // migrations/0137_add_column_bar.sql (true next number in sequence) |
Explanation (EN)
Rebase onto the latest base branch and regenerate the migration right before merging so its number reflects the actual next slot in the sequence — don't assume a clean git merge means the numbering is still safe.
Objašnjenje (HR)
Rebaziraj na najnoviju baznu granu i regeneriraj migraciju neposredno prije spajanja kako bi njezin broj odražavao stvarno sljedeće mjesto u nizu — ne pretpostavljaj da čist git merge znači da je numeracija i dalje ispravna.