We’ve been reevaluating our Git strategy for database changes. Historically, our team maintained one branch per environment—dev, qa, and prod. While it gave us some flexibility, it created a lot of overhead: merge conflicts, forgotten hotfixes, and inconsistent deployment behavior.
Recently, we adopted a trunk-based model paired with Liquibase for change management. Instead of branching per env, we:
Keep all changelogs in a single main branch
Use Liquibase contexts to control env targeting
Promote via automated pipelines
Apply GitOps principles for traceability and rollback
Curious—how are others approaching Git branching for DB changes? Is anyone still using GitFlow or feature/env branches? Anyone managing this at scale with other tools like Flyway or Atlas?
Recently, we adopted a trunk-based model paired with Liquibase for change management. Instead of branching per env, we:
Keep all changelogs in a single main branch Use Liquibase contexts to control env targeting Promote via automated pipelines Apply GitOps principles for traceability and rollback
Curious—how are others approaching Git branching for DB changes? Is anyone still using GitFlow or feature/env branches? Anyone managing this at scale with other tools like Flyway or Atlas?
Would love to hear real-world stories.