Abstract Keyboard Shortcuts
Abstract's whole premise is applying Git's branching-and-merging model to design files, which historically lacked any real version control beyond manually saved copies with names like 'final_v3_ACTUALLY_FINAL,' and its shortcut set borrows conceptual vocabulary directly from Git even though the underlying implementation is necessarily different since design files aren't line-based text. Creating a new branch to work on a design change in isolation, then merging it back once reviewed, follows the same conceptual shape as a Git feature-branch workflow, letting multiple designers work on different parts of the same file without directly overwriting each other's changes the way a single shared Sketch file with no version control would risk. Because visual diffing (seeing exactly what changed between two versions of a design) is fundamentally harder to represent than a text diff, Abstract's review and comparison shortcuts lean on side-by-side and overlay visual comparison views rather than the line-by-line diff format Git-based code review tools use, reflecting a genuinely different technical challenge underneath a conceptually similar branching workflow. Design teams that adopted Abstract early were often the same teams frustrated by shared-drive design file chaos — multiple designers overwriting each other's saved versions of the same master file, or losing track of which copy actually reflected the latest approved decisions — and the branch/merge/review model exists specifically to give design work the same accountability and traceability engineering teams had already taken for granted through Git for years. This page is aimed at design teams that have already adopted, or are seriously evaluating, a Git-inspired workflow for design files rather than a solo designer working alone, since branching and review are fundamentally collaborative concepts that provide little benefit without other people also working in the same project. If your team already uses Git for code, expect the conceptual vocabulary here — branch, commit, merge, review — to require zero relearning, with the actual adjustment being how visual, rather than textual, the review and comparison experience is compared to reviewing a code pull request.
Branching Commits
| Action | Windows | Mac | Description |
|---|---|---|---|
| Create new branch | New Branch button (no dedicated key) | — | Creates a new branch from the current state of a design file, letting a designer work on changes in isolation before merging back, conceptually mirroring a Git feature branch. |
| Commit changes to branch | Commit button + message (no dedicated key) | — | Saves the current state of design file changes as a commit with a descriptive message, building a version history for the branch similar in spirit to a Git commit, though scoped to design file changes rather than text diffs. |
| Merge branch into main | Merge button (no dedicated key) | — | Merges a completed branch's changes back into the main line of the project, following the same conceptual branch-and-merge model as Git, adapted for design files. |
| Revert to a previous commit | History panel > select commit > Revert | — | Restores the design file to the state it was in at a specific earlier commit, useful for undoing a change that's already been committed and possibly merged, without manually reconstructing the earlier version by hand. |
| Delete a branch | Branch settings > Delete Branch (no dedicated key) | — | Removes a branch that's already been merged or is no longer needed, keeping the project's branch list from accumulating clutter over time, similar to deleting a stale feature branch after it's been merged in a Git-based workflow. |
Review Comparison
| Action | Windows | Mac | Description |
|---|---|---|---|
| Open a review/pull request for a branch | Create Review button (no dedicated key) | — | Opens a review request for a branch's changes, similar in concept to a Git pull request, letting teammates comment and approve before merging. |
| Compare two versions visually | Select two commits > Compare | — | Shows a visual side-by-side or overlay comparison between two versions of a design file, Abstract's approach to visual diffing since design changes can't be represented as simple line-based text diffs the way code changes can. |
| Leave a comment on a design element | Click element in review > Add Comment | — | Adds a comment pinned to a specific design element within a review, part of Abstract's collaborative review workflow for design changes. |
| Approve a pending review | Approve button in review (no dedicated key) | — | Marks a review as approved by the reviewing teammate, typically a required or expected step before the branch's author proceeds to merge the changes into the main line. |
| Request changes on a review | Request Changes button in review (no dedicated key) | — | Flags a review as needing further work before it can be merged, similar to requesting changes on a Git pull request, giving the branch's author clear feedback to address before resubmitting for approval. |
Navigation
| Action | Windows | Mac | Description |
|---|---|---|---|
| Browse project commit history | History panel (no dedicated key) | — | Shows the full commit history for a project across all branches, letting you review how a design file has evolved over time, similar in spirit to browsing Git log/history. |
Frequently Asked Questions
Does Abstract work with Figma files, or only Sketch?
Abstract's deepest integration has historically been with Sketch files specifically, given its origins addressing Sketch's lack of native version control; Figma has since added its own built-in version history and branching-like features directly into the product, reducing some of the original need for a separate tool like Abstract specifically for Figma-based teams.
How is visual diffing in Abstract different from a text-based diff in Git?
Text-based diffs can show precisely which lines changed by comparing character-by-character. Design files are fundamentally visual and structural rather than line-based text, so Abstract instead shows side-by-side or overlay visual comparisons between two versions, which communicates what changed visually but doesn't have the same line-level precision a code diff offers.
Why would a design team need branching if only one person typically edits a given screen?
Even with one primary owner per screen, branching protects against accidental overwrites when multiple people touch a shared file (like a shared component library used across a whole design system), and it provides a safe space to experiment with a design change without affecting the main, presumably-stable version other team members and stakeholders are viewing.
Does reverting to a previous commit undo any work that was built on top of it since?
Reverting creates a new state matching the selected earlier commit, but it doesn't erase the intervening commit history itself — later commits still exist in the project's history and can be reviewed or, if the revert turns out to be a mistake, the more recent state can typically be restored again from its own commit, similar to how Git's revert doesn't destroy history but adds a new state on top of it.
Is a review approval in Abstract a hard technical gate, or just a social convention?
This depends on how a team configures their workflow — Abstract can support required approvals before merging as an enforced project setting, similar to a branch protection rule in Git-based code hosting, though many smaller teams treat approval more as a social convention and communication step than a hard technical block, especially on projects without formally configured merge restrictions.
What typically happens after a reviewer requests changes rather than approving?
The branch's author addresses the flagged feedback with additional commits on the same branch, then either resubmits the same review for another look or opens a fresh review depending on team convention, mirroring how a Git pull request stays open through multiple rounds of feedback and revision rather than needing to be closed and recreated after each round of requested changes.