How to Version Control AI-Generated Slide Decks
A practical guide to version controlling AI-generated slide decks: picking a source format, using Git, naming files, reviewing changes, and rolling back bad edits.
Author: Variant Team. Variant is built by a small team working on HTML-native presentation tools, MCP workflows, and agent-editable decks.
If you've ever opened a folder called decks and stared at six files named pitch_final.pptx, pitch_final_v2.pptx, pitch_FINAL_real.pptx, you already know the problem. It gets worse the moment an AI tool joins the workflow. One prompt rewrites four slides. The next one undoes a headline you actually liked. By Friday afternoon, nobody on the team can say with confidence which file is the version you presented on Tuesday.
This is a guide to fixing that. It's about formats, Git habits, naming, review, and the boring but useful question of how to roll back when an AI edit goes sideways.
#Quick answer
| If you want to... | Do this |
|---|---|
| Diff slide changes line by line | Keep the source in a text format (HTML, Markdown, or JSON) and commit it to Git |
| Roll back a bad AI edit | Save snapshots before any prompt that touches multiple slides |
| Share a fixed copy with reviewers | Export to PDF and send the file, not a live link |
| Hand a deck to non-technical editors | Export to PPTX and treat it as a one-way handoff |
| Track who changed what across a team | Use Git for source, with conventional commit messages and tags for presented versions |
The rest of this article walks through each of those, and a few of the smaller decisions that decide whether your setup actually holds up after a month of use.
#Why AI changes the math on version control
Human deck edits are slow. You move a box, swap a color, rewrite a sentence, save. The blast radius of any single change is small, and the editor's undo button covers most mistakes.
AI edits are bulk operations. You ask for "tighter copy across the deck" and twelve slides change at once. You ask for "a more modern look" and the model rewrites the layout, the type scale, and a chart you didn't want touched. Each prompt is a potentially destructive batch, and the time between "this looks great" and "wait, what just happened" is measured in seconds.
Without history, you're operating without a net. With history, you can:
- Compare two AI variants of the same slide
- Restore a slide the model "improved" into something worse
- Branch a deck for a different audience without losing the original
- Hand a reviewer a stable snapshot while you keep iterating
- Audit what an autonomous agent actually changed in your deck overnight
That's the case for taking version control seriously. Now the practical question: what should you actually do.
#Pick a source format that diffs cleanly
The single biggest decision is what file you treat as the source of truth. Everything else follows from this.
The friendly formats are text. HTML and CSS, Markdown, JSON, YAML. They open in any editor, they read like documents, and Git can show you exactly which lines changed between commits. AI coding agents can also edit them in place without rewriting the whole file, which matters more than it sounds.
The unfriendly formats are binaries. PPTX is a zip of XML and embedded media. Keynote is a proprietary bundle. Both can technically be committed to Git, and people do, but the experience is grim:
git diffon a binary tells you the file changed and nothing else- Merge conflicts can't be resolved in any normal way
- Repository size grows fast because images get duplicated on every save
- Pull request reviewers have to download and open the file to see anything
- AI tools usually have to regenerate the whole deck to make a small edit
Google Slides sits in a third category. It's cloud-only with built-in revision history, which is genuinely useful, but you can't pull the file down into Git, branch it, or hand it to a coding agent that lives outside Google's product. If your team's review process happens entirely inside Google Drive, that may be fine. If you want a portable, inspectable source, it isn't.
A reasonable rule: if you can't read the source in a normal editor, it isn't your source format. Pick something text-based, then export to PPTX or PDF when you need to hand a fixed copy to someone.
#A Git workflow that actually fits decks
Once the source is text, the rest is mostly the same Git habits you'd use for any small project, with a few twists.
One repo per program, not per deck. A repo with one deck in it is awkward. A repo with every deck a team has ever made is also awkward. The sweet spot is usually one repo per customer, product line, or recurring workstream. Inside, give each deck its own folder, with assets and notes alongside the source file.
Commit before you prompt, not after. This is the habit that pays for itself the most. If you're about to ask an AI to "redesign these slides" or "rewrite the script," commit the current state first. That way the prompt's output is a single diff you can read, accept, or throw away. Committing after the fact loses the before-state, which is exactly what you'd want to compare against.
Use messages that explain why. A commit message like "updates" tells future-you nothing. "Tightened intro after dry run with sales" tells you what you were thinking and what feedback drove the change. The same applies to AI edits: note that an agent did the work and what you asked for. "AI rewrite of pricing section, prompt: more punchy" is short and useful.
Tag presented versions. Whenever a deck actually gets shown to an audience, tag the commit. board-2026-04, customer-acme-q2, whatever scheme fits. Tags are cheap, and they're the only reliable way to answer "what did we actually present" three months later.
Branch for audience variants. The board version and the customer version of the same deck are rarely identical. A branch per audience, with shared updates merged back into a main, beats six near-duplicate files in a folder. If branches feel heavy, even separate folders inside a single deck directory work, as long as you're explicit about which is which.
Keep exports out of Git. PDFs and PPTX files are build outputs. They balloon repo size, they don't diff, and they go stale the moment the source changes. Generate them on demand, send them, and let them live in email or a shared drive.
#Naming files like you'll come back in six months
File naming is unfashionable to talk about and pays back forever. A few rules that hold up:
- Lead with the audience or purpose, not the date:
acme-pitch.htmlbeats2026-04-22-deck.html. - Use dates only when they're meaningful, and write them
YYYY-MM-DDso they sort correctly. - Avoid
final,v2,real,actual, and any other word that implies the file ahead of it is a lie. That's what Git history is for. - If you must keep multiple variants in a folder, use a suffix that describes the variant, not its order:
pricing-deck-short.html,pricing-deck-technical.html. - Match folder names to the audience or program, not the year, so they don't drift out of relevance.
The same rules go for branch names. customer-acme is a better branch than feature-2. You will thank yourself.
#Reviewing AI-generated slide changes
Reviewing a deck change is different from reviewing code. Nobody wants to read a wall of HTML diff for a slide. But the diff is still where the truth lives, so a useful review usually combines two things.
First, look at the diff for content changes. AI tools love to "improve" copy in ways that subtly change the meaning. A pricing tier becomes "starting at" instead of "from." A claim gets stronger than the data supports. A name gets corrected to the wrong spelling. These slip past the eye on a rendered slide but jump out in a text diff.
Second, render the deck and look at the actual slides. Layout regressions don't show up well in a diff. A heading that wraps awkwardly, a chart that's clipped, a color that drifted half a shade darker, those are visual problems and need a visual review. Most teams set up a simple preview command (npm run preview or equivalent) that renders the source so reviewers can flip through.
If the deck lives in a Git host with pull requests, the same review primitives work fine. Open a PR, attach a rendered PDF or screenshots, and let a teammate sign off. Treat decks heading to important audiences with the same care you'd treat a release.
#Rolling back when an AI edit goes wrong
The single most common version control task with AI decks is "undo the last thing the model did." There are three layers of rollback to know about.
The editor's undo button is your first line of defense. It's instant, it's per-keystroke, and it's enough for typos and small slips. It also vanishes the moment you close the file or the tab, which is why it can't be the whole story.
Git is your second line of defense, and it's the strongest one. If you committed before the prompt, rolling back is a single command (git revert for keeping the history, git reset for rewriting it). If you didn't, you're back to manual fixes. This is the entire reason "commit before you prompt" is a habit worth building.
Snapshots inside whatever tool you use are the third line. Many AI slide generators and editors keep their own internal history, separate from Git. The granularity is usually finer than your commits, since the tool saves on its own schedule. Treat that as a per-session safety net, not a long-term archive. The thing you actually present should be the thing in Git, with a tag.
A useful mental model: the editor handles seconds, the tool handles a session, Git handles the project. You don't pick one. They stack.
#What "good" looks like for a small team
If you put it all together, a working setup for a team running AI-generated decks at any scale looks roughly like this:
- One Git repo per program, with one folder per deck
- Source files in a text format, committed at meaningful checkpoints
- A short
README.mdper deck noting audience, last-presented date, open questions - Commit-before-prompt as a team habit, with prompts noted in the commit message
- Tagged commits for any deck that's been externally presented
- PDFs and PPTX files generated on demand, never committed
- A simple preview command so reviewers can see slides without setting up tools
None of this is exotic. It's the same set of habits a small engineering team would use for any text-based project. The only thing AI changes is the frequency and size of edits, which makes the habits more valuable, not less.
#Related reading
- Why HTML Beats Images for AI-Generated Slides
- Build Agent-Editable Presentation Decks with MCP
- How Engineering Teams Can Vibe Code Technical Presentations
#FAQ
Can I put a PPTX file in Git and call it version controlled? Technically yes, practically no. The file is a binary, so diffs are useless, merges conflict, and the repo grows fast. If your tool only outputs PPTX, you're better off keeping the source somewhere else and treating the PPTX as a build output.
Is Google Slides revision history enough on its own? For a single person on a single deck, often yes. For a team that needs branches, audience variants, or the ability to hand a deck to a coding agent, no. The history is locked inside Google Drive and the format isn't portable.
How often should I commit? Before any AI prompt that will touch more than one slide. After any change you'd be sad to lose. At natural pauses, like before a review or a presentation. Daily is usually too coarse; per-keystroke is too fine. The commit-before-prompt habit covers most of it.
What about the assets, like images and videos? Small images can live in the repo next to the deck. Large media (video, high-res photos) usually belong in a shared drive or an asset host, with the deck referencing them by URL. Git LFS works if you really want everything in one place.
Should AI prompts go in the commit message? A short version, yes. The exact prompt and the model's response are useful context when you're trying to remember why the deck looks the way it does. A line like "AI: tighten copy across intro" is enough most of the time. Save longer prompt logs alongside the deck if you want a full record.
Do branches actually make sense for slide decks? For one-off decks, no. For recurring decks with multiple audiences, yes. A board version, a customer version, and an all-hands version of the same underlying story all benefit from being branches that can share updates without overwriting each other.
How do I review a deck change in a pull request? Combine the text diff with a rendered preview. The diff catches content changes the eye misses. The render catches layout regressions the diff hides. Most teams attach a PDF or a few screenshots to the PR so reviewers don't need to run anything locally.