The database role definitions sat scattered across migrations, scripts, and documents. Bad merges had buried clear permissions under tangled branches. You needed a clean history. You needed granularity.
Git rebase can solve this. Not as a vague best practice, but as a sharp tool for controlling how granular database roles are applied, tracked, and reviewed. By rewriting commit history, you align role changes with the actual evolution of your schema. You strip noise. You surface intent.
Granular database roles mean each role is defined with exact privileges—no overreach, no missing rights. In large systems, this granularity protects data, simplifies audits, and reduces accidental privilege escalation. When combined with Git rebase, you gain the ability to reorder, edit, and squash commits related to role creation and modification.
This approach starts with isolation. Keep role changes in separate branches from core schema changes. Use interactive rebase to place commits in logical sequence, making sure each rebase step reflects the actual timeline of privileges. The resulting history becomes a high-fidelity record: role A gained read access in commit 42; role B lost write access in commit 73.