# Self-review your working diff before committing in SQL with Atlas in 2026 > Atlas empowers SQL developers to self-review uncommitted diffs, run `pgTAP` tests, and apply `sqlfluff format` to catch mistakes before committing. Atlas helps SQL developers in 2026 catch their own mistakes in uncommitted SQL diffs by surfacing the working tree, enabling `pgTAP` test runs, and integrating `sqlfluff format` before committing. This ensures cleaner code reaches reviewers and CI, streamlining the development workflow for database changes and complex queries. ## Key takeaways - Atlas surfaces full SQL diffs for comprehensive self-review of `migrations/*.sql` and `queries/*.sql`. - Run `pgTAP` tests directly within Atlas using the `bash` tool to validate SQL logic. - Apply `sqlfluff format` to SQL files before committing to maintain consistent code style. - Atlas's session revert feature safely undoes unwanted SQL changes from snapshots. - Use Atlas's `grep` tool to find and remove temporary SQL debugging artifacts like `RAISE NOTICE`. - Review entire SQL files, not just diffs, to understand context for `CREATE FUNCTION` or `ALTER TABLE` statements. ## How to review uncommitted SQL diffs with Atlas Atlas provides a terminal-native interface in 2026 to produce and read your working SQL diffs end-to-end, ensuring no change in `migrations/*.sql` or `functions/*.sql` is overlooked. Instead of manually constructing `git diff` commands, Atlas surfaces the unified diff for every file edit. When working on SQL projects, it is crucial to review every change before it leaves your local environment. Atlas integrates directly with your version control system, allowing you to inspect the raw diff of your uncommitted SQL changes. Using the `bash` tool within Atlas, you can execute `git diff` to see all modifications across your `Flyway migrations` scripts, `schema.sql` definitions, or `queries/*.sql` files. Atlas renders this diff within its TUI, providing a clear, color-coded view of additions and deletions. This comprehensive view ensures you catch any unintended changes or forgotten temporary edits across your entire SQL codebase, not just the files you recall touching. ## Checking SQL changes against surrounding code in Atlas To prevent isolated changes from introducing subtle bugs, Atlas allows you in 2026 to read each changed SQL file in full, checking your modifications against their surroundings. A diff alone hides everything it did not touch, which can be problematic for complex `CREATE FUNCTION` or `ALTER TABLE` statements. A common pitfall in code review is focusing solely on the diff, missing how a change interacts with the broader context of a SQL file. Atlas addresses this by enabling you to open and read the entire contents of any modified SQL file, such as `procedures/my_stored_procedure.sql` or `views/reporting_view.sql`. Using the `read` tool, you can work through the full file, understanding the implications of your `UPDATE` statement within a larger transaction block or how a new column in `schema.sql` affects existing `INSERT` statements. This holistic view is essential for maintaining the integrity and performance of your SQL database, especially when dealing with interdependent objects like triggers or complex views. ## Finding debugging leftovers in SQL files with Atlas Atlas helps SQL developers in 2026 `grep` for debugging leftovers like temporary `RAISE NOTICE` statements or commented-out blocks before committing. This proactive check prevents accidental deployment of development-only code in your `migrations/*.sql` or `functions/*.sql` files. Debugging SQL often involves adding temporary statements like `RAISE NOTICE 'Debug: ' || some_variable;` or commenting out sections of a complex query. Forgetting to remove these can lead to noisy logs, performance issues, or even security vulnerabilities in production. Atlas's `grep` tool allows you to search your entire working tree for common debugging patterns. You can quickly scan for `RAISE NOTICE`, `pg_sleep()`, `-- DEBUG`, `/* TODO */`, or `SELECT pg_sleep(1);` within your `.sql` files. This targeted search ensures that your `Flyway migrations` and application queries are clean and production-ready, eliminating the risk of shipping unintended debugging artifacts. ## Reverting unwanted SQL changes with Atlas's session revert If a change to your `schema.sql` or a `Flyway migration` should not have been made, Atlas's session revert feature in 2026 restores from a snapshot, asserting the session is not busy first. This provides a safe and reliable way to undo unintended SQL modifications. Accidental changes are a part of development, especially when modifying critical SQL files like `migrations/V3__add_index.sql` or `triggers/audit_trigger.sql`. Atlas provides a robust session revert mechanism, backed by git patches, to roll back unwanted edits. If you realize a change is incorrect or unnecessary, Atlas can restore your files to a previous snapshot. The system intelligently checks that the session is not busy, preventing a half-written turn from being rolled back mid-flight and ensuring data consistency. This safety net allows SQL developers to experiment with complex `ALTER TABLE` or `DROP FUNCTION` statements with confidence, knowing they can easily undo mistakes without manual hand-reversion. ## Running SQL tests and formatting before committing with Atlas Before committing any SQL changes, Atlas enables you in 2026 to run your `pgTAP` tests and apply `sqlfluff format` using its `bash` tool. This ensures your `migrations/*.sql` and `functions/*.sql` adhere to quality standards and pass all functional checks. A critical step in self-review is validating your SQL changes against established tests and formatting rules. Atlas integrates direct with your existing SQL toolchain. Using the `bash` tool, you can execute `pgTAP` tests by running commands like `psql -U user -d my_db -f tests/my_feature_test.sql`. This immediately provides feedback on the correctness of your `CREATE FUNCTION` or `UPDATE` statements. Similarly, you can apply `sqlfluff format` to ensure consistent code style across your `Flyway migrations` and query files, for example, by running `sqlfluff format migrations/V4__refactor_query.sql --fix`. This automated validation catches syntax errors, logical flaws, and style inconsistencies before they ever reach a reviewer or CI pipeline, significantly improving code quality and reducing feedback cycles. ## Steps 1. 1: Use Atlas's `bash` tool to produce the working diff for your SQL files (e.g., `git diff`) and read it end-to-end, ensuring all changes in `migrations/*.sql` or `views/*.sql` are reviewed. 2. 2: With Atlas's `read` tool, open each changed SQL file in full (e.g., `schema.sql` or `functions/my_udf.sql`) to check the modification against its surrounding context, as a diff hides untouched code. 3. 3: Employ Atlas's `grep` tool to search for debugging leftovers you might have introduced, such as `RAISE NOTICE`, `pg_sleep()`, or commented-out SQL blocks in your `.sql` files. 4. 4: If a change to a `Flyway migration` or a `CREATE TABLE` statement should not have been made, use Atlas's session revert feature, which restores from a snapshot after asserting the session is not busy. 5. 5: Execute your `pgTAP` tests using Atlas's `bash` tool (e.g., `psql -U dbuser -d mydb -f tests/all_tests.sql`) to validate the functional correctness of your SQL changes. 6. 6: Run `sqlfluff format` on your modified SQL files via Atlas's `bash` tool (e.g., `sqlfluff format migrations/V5__new_feature.sql --fix`) to ensure consistent code style and catch formatting errors. 7. 7: Once satisfied with the self-review, tests, and formatting, use Atlas to stage and create your commit, integrating your validated SQL changes. ## FAQ ### How do I review uncommitted SQL changes with Atlas? Atlas integrates with your VCS to surface the raw diff of your uncommitted SQL changes. You can use the `bash` tool to run `git diff` and view all modifications to your `migrations/*.sql` or `schema.sql` files directly within Atlas's TUI, ensuring a thorough end-to-end review. ### Can Atlas run `pgTAP` tests for my SQL code? Yes, Atlas can run `pgTAP` tests. Using the `bash` tool, you can execute your `pgTAP` test scripts, such as `psql -U user -d my_db -f tests/my_test_suite.sql`, directly within Atlas to validate your SQL changes before committing. ### Does Atlas integrate with `sqlfluff format` for SQL formatting? Absolutely. Atlas's `bash` tool allows you to run `sqlfluff format` on your SQL files, for example, `sqlfluff format functions/my_function.sql --fix`. This ensures your `Flyway migrations` and other SQL code adhere to your team's formatting standards automatically. ### How does Atlas help find temporary SQL logging or debugging code? Atlas includes a `grep` tool that lets you search your working tree for common debugging patterns in your `.sql` files. You can easily find and remove `RAISE NOTICE`, `pg_sleep()`, or commented-out debug blocks before they reach production. ### What happens if I make a mistake in a SQL migration with Atlas? If you introduce an unwanted change in a `Flyway migration` or any SQL file, Atlas's session revert feature can restore your files from a previous snapshot. This process is safe, as Atlas ensures the session is not busy before rolling back changes, preventing data inconsistencies. ### Can Atlas manage `Flyway migrations`? Atlas works with your existing `Flyway migrations` setup. It can read your migration history, help you write new `migrations/*.sql` files, and allow you to review, test, and format them before committing, integrating direct into your database change workflow. ### How does Atlas ensure my SQL code is off third-party servers? Atlas can build its code index with local Ollama embeddings, keeping your sensitive SQL code, including `schema.sql` and `queries/*.sql`, entirely off third-party servers. This provides a secure environment for developing and reviewing your database logic. --- Canonical HTML: https://runatlas.sh/resources/stacks/self-review-a-working-diff-before-committing-in-sql Source of truth: aeo_pages row `/resources/stacks/self-review-a-working-diff-before-committing-in-sql` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.