Should SourceTree rollback operations warn about untracked schema changes or remain git-only focused?

Schema Change Safety During Git Rollbacks in SourceTree

SourceTree provides visual access to git reset --hard and git checkout operations for reverting commits. However, the application does not track or coordinate database schema migrations, which are typically managed through separate tools like Flyway, Liquibase, or custom migration scripts.

The core constraint is that SourceTree operates solely at the git layer, while schema changes often exist outside version control or in separate migration files. When users perform a rollback through SourceTree's GUI, there is no built-in mechanism to verify that corresponding schema reversals have been or will be executed.

This creates a potential safety gap where developers may reverse code changes without considering the database state implications. The GUI does not currently warn about this disconnect, leaving users responsible for manual coordination between git operations and migration management.

Two approaches emerge: (1) SourceTree could integrate warnings about potential schema mismatches when rolling back commits that modify migration files, or (2) maintain its current git-focused scope and require external tooling for coordinated rollbacks. Which approach better serves users working with schema-managed repositories?

Does SourceTree provide any indication when a rollback operation affects tracked migration files? Should the application detect and flag commits that modify schema migration scripts versus pure application code changes?