Why this matters
- Typical tasks: undoing a faulty commit, restoring a deleted SQL script, reverting a merge, rolling back a release tag, or restoring a dataset/report version.
- Outcome: faster incident recovery with minimal risk to your team’s history and collaboration.
Concept explained simply
Rollback means returning code or assets to a previous good state. Restore is bringing back specific files or data you lost or changed by mistake. In Git, you have safe, history-preserving ways (revert, restore) and history-rewriting ways (reset) for local fixes.
- git revert: creates a new commit that undoes a previous commit. Safe for shared branches.
- git restore (or checkout -- for older Git): recovers file content from a specific commit without rewriting history.
- git reset: moves your branch pointer. Great for local cleanup; risky on shared branches (especially --hard).
Mental model
Think of your repo as a timeline of snapshots (commits). Revert adds a new snapshot that cancels an old one. Restore copies a file from an earlier snapshot into now. Reset moves your label on the timeline—others may not follow, so only use it when no one else relies on your timeline.
Safety first checklist
- Confirm the last known good commit (build/tests pass, KPI looks right).
- Work on a branch for experiments; only push tested reversions to main.
- Avoid git reset --hard on shared branches.
- Sync with remote before rollback (git fetch; ensure you’re up to date).
- Communicate: note which commit or release is being rolled back and why.
Worked examples
1) Undo a bad commit on a shared branch (safe)
Scenario: A commit changed a KPI calculation incorrectly.
- Identify commit hash: git log --oneline
- Revert safely: git revert <bad_hash>
- Resolve conflicts if prompted, then git commit (if not auto-created).
- Push: git push
What happens
Git creates a new commit that applies the inverse of the bad commit. History remains linear and intact.
2) Restore a deleted SQL file
Scenario: A teammate deleted dims/customer.sql accidentally.
- Find last good commit: git log -- dims/customer.sql
- Restore file content: git restore --source <good_hash> -- dims/customer.sql
- Review and commit: git add dims/customer.sql; git commit -m "Restore customer dimension"; git push
Older Git alternative
git checkout <good_hash> -- dims/customer.sql
3) Revert a merge commit that broke production
Scenario: A merged PR broke the nightly pipeline.
- Find merge commit: git log --merges --oneline
- Revert with -m to specify mainline parent: git revert -m 1 <merge_hash>
- Resolve conflicts, test locally, push.
Choosing -m 1 vs -m 2
-m 1 keeps the main branch as the base; -m 2 keeps the feature as base. For typical cases, use -m 1 on the main branch.
Rolling back BI/database artifacts
- Power BI Desktop/Service: use versioned .pbix in Git. To roll back, restore a previous .pbix from Git and publish. If using deployment pipelines or version history, select a prior version there.
- SQL schema/data: prefer migrations with reversible scripts. To roll back, apply a down migration or run a known-good release tag’s migration set. For data fixes, use idempotent scripts and verify with SELECT checks.
- Tagged releases: git tag v1.4.2 at a known-good commit. To roll back an app/report deployment, checkout the tag, rebuild, redeploy.
Minimal downtime rollout plan
- Identify last good tag/commit.
- Create a hotfix/revert branch, apply revert/restore.
- Run tests and validate key KPIs locally or in staging.
- Deploy revert build; monitor data refresh/jobs.
- Post-mortem: root cause, guardrails, tests.
Who this is for and prerequisites
Who this is for: BI Developers working with Git, SQL transformations, and BI reports/datasets who need safe rollback habits.
Prerequisites:
- Basic Git (clone, commit, push, pull)
- Comfort with your BI tool (e.g., Power BI) and SQL
- Ability to run a test/staging environment
Learning path
- Start here: Revert vs reset vs restore
- Next: Branching models for safe releases
- Then: Code review and release tags
- Later: CI/CD with automated tests and migrations
- Advanced: Database migration frameworks and feature flags
Common mistakes and self-check
- Using git reset --hard on main: prefer git revert on shared branches.
- Forgetting to fetch before rollback: leads to conflicts. Run git fetch first.
- Rolling back without tests: verify KPI queries and refreshes before pushing.
- Restoring the wrong commit: confirm with git show <hash> or compare diffs.
- Skipping communication: announce the rollback scope and tag/commit.
Quick self-check
- git status is clean before push?
- Main branch history shows a Revert commit rather than force-push?
- Key dashboards show expected values after rollback?
Exercises you can do now
Mirror these steps in your own sandbox repo. Use dummy data only.
Exercise 1: Safe rollback with git revert
- Create a commit that intentionally changes a KPI SQL line.
- Revert that commit using git revert.
- Run a validation query to confirm the KPI is back to normal.
Exercise 2: Restore a deleted file
- Delete dims/customer.sql and commit the deletion.
- Use git restore (or checkout) to bring it back from a previous commit.
- Commit and push the restoration.
Need a hint?
- Use git log --oneline to find commit hashes.
- Use git restore --source <hash> -- path/to/file for single-file restore.
- Revert merges with git revert -m 1 <merge_hash>.
Practical projects
- Release rollback drill: Tag a release, deploy to a test environment, introduce a breaking change, then roll back to the tag. Document steps and timings.
- Report version rescue: Maintain .pbix in Git. Delete a visual, commit, then restore the prior .pbix and republish to test workspace.
- Migration safety net: Write an up/down SQL migration that changes a column and computes a metric. Practice applying up then down in a sandbox DB.
Mini challenge
Your latest deployment broke the revenue KPI after merging three commits. Under time pressure, outline the exact commands and checks to revert safely on the shared main branch, restore the last known good state, and verify dashboards. Keep your plan to 5–7 bullet points.
Next steps
- Make a rollback playbook template (who to notify, commands, verification queries, dashboards to check).
- Create a habit: tag each production release and keep a short changelog.
- Add a pre-merge checklist that includes a rollback test in staging.
Test and progress
The quick test below is available to everyone. If you are logged in, your progress will be saved automatically.