Git for video

There is a category of tool that promises "version control for designers" every few years. Abstract had a moment. Plant had a moment. Figma's version history. Frame.io's review system. Each of these solves a real problem and stops short of the thing software engineers have had since 2005. They give you snapshots, not history. You can roll back, but you cannot diff. You can comment, but you cannot blame.

HyperFrames compositions are HTML. HTML is text. Text fits in git. This sounds like a small technical detail until you have spent six months using it. Then it sounds like the most important feature the tool has.

I want to spend this post walking through what git-for-video actually looks like in practice — what branches mean, what code review of a motion design looks like, what the rollback button does — and why the alternative tools cannot do these things even when they want to.

The shape of the problem

Motion design has a collaboration problem nobody likes to talk about. Three designers on one project. Each one has a copy of the AE file. They make changes in parallel. At some point, somebody has to merge their changes. There is no merge. There is one person opening four versions of the file and copy-pasting layers, hoping nothing breaks.

I have watched senior motion designers spend half a day reconciling versions of a 45-second spot. The agency I worked at before HyperFrames had a rule: only one person could touch the project file at a time. The rule was enforced by Slack message. Sometimes it broke.

This is not a tool problem. It is an artifact problem. Binary files do not merge. Three-way merge requires the merge algorithm to understand structure, and AE projects are an opaque blob from git's perspective. The best git can do is "use mine" or "use theirs," which is not version control. It is a lottery.

When the composition is HTML, git's three-way merge works. Two designers can edit different sections of the same file and git stitches the changes together. Conflicts happen, and conflicts are resolvable, because git can see what each side changed. The whole class of "I lost two hours of work because Slack said it was my turn but I didn't see the message" goes away.

What a meaningful diff looks like

Let us go through a real one. A designer on my team made a change to a hero composition last week. Here is the relevant slice of the diff:

   .title {
     font-size: 96px;
-    font-weight: 500;
+    font-weight: 600;
     letter-spacing: -0.02em;
-    animation: rise 700ms cubic-bezier(.2,.7,.1,1) 200ms backwards;
+    animation: rise 900ms cubic-bezier(.16,1,.3,1) 200ms backwards;
   }

Four lines of change. Two changes. The font-weight got heavier. The easing got more cinematic and a bit longer. When this diff hit my pull request inbox, I could read the intent: "make the title land harder."

I left a comment on line 4. "Let's try 240ms delay instead of 200ms — gives the backdrop a beat more time to settle." She replied. We went back and forth twice. We merged. The whole exchange happened in GitHub, in async, with both of us looking at the same numbers.

Try doing this in After Effects. There is no review interface. There is no inline comment. There is no way to say "let's try 240ms instead of 200ms" without opening the file, finding the keyframe, recording a screen capture, and posting it in Slack. The medium of conversation has to change every time, and every change loses fidelity.

Branches as variants

Here is where it gets interesting. In git, branches are cheap. You can have a hundred branches. Most exist for a day. They are how you experiment.

For video, this maps to variants. We have a campaign coming up — a fintech launch — and the brief calls for fifteen variants of the same 15-second spot. Same structure, different copy, different colors per market, different durations for some platforms. The traditional approach is fifteen AE files in fifteen folders.

The HyperFrames approach is one main composition and fifteen branches off it. Each branch differs from main by a small diff: this line of copy, this color token, this duration. When we discover an improvement in one branch, we cherry-pick the commit back to main. When main improves (a new easing curve, a better caption position), every variant rebases and inherits the improvement.

The discipline is the same as software branching: keep diffs small, merge often, name branches descriptively. The result is a campaign that ships as a coherent set, not as fifteen drifted copies that each have a different version of "the same" thing.

What code review of a motion design feels like

I want to describe this concretely because it surprised me how natural it became.

A PR lands in our queue. The title is "Tighten the title rise easing on hero composition." I open the PR. GitHub shows me the diff: three lines. I open the preview link in the PR description — every PR has a deploy preview that renders the composition, wired up through the GitHub Actions integration and posted from a Vercel preview deploy. I scrub through. I watch the before-and-after on the same screen. I leave a single comment on the line that changed: "Yes, much better. Approving."

The whole interaction takes ninety seconds. The reviewer (me) and the author (a colleague) never get on a call. There is a permanent record. The merged commit is forever attributable.

Compare to a typical motion design review. The designer exports the file as an MP4. They DM it to the reviewer. The reviewer watches it. They reply with a paragraph of feedback. The designer interprets the paragraph, makes changes, exports again, DMs again. Three rounds later, the file ships. Nobody remembers exactly what was reviewed. The MP4 link expires. There is no audit trail.

The first time I shipped a motion design change as a pull request and saw it go through code review, I realized this was the missing piece. Motion design has been a craft without process. Process is what makes work scale beyond one designer.

Rollback as a verb

There is a feature in HyperFrames I use approximately weekly. I do not advertise it because it is so boring that nobody asks about it. I will advertise it now.

git checkout HEAD~3 -- composition.html && hyperframes render

That command reverts the composition to three commits ago, renders it, and writes a new MP4. Total time, about ten seconds. The client said "can we see what it looked like before yesterday's change?" I have an answer in ten seconds. Not "let me find the old project file." Not "let me re-export from the backup." A real answer, derived from real history, with the actual change reverted.

The MP4 output has a sidecar manifest that records the commit hash. Two weeks from now, when someone asks "where did this MP4 come from?", the manifest answers. We know the exact source. We can regenerate.

This is the boring superpower of putting compositions in git: every render is reproducible from its source. The MP4 is never the source of truth. The commit is. When the MP4 is lost, deleted, corrupted, or out of date, we generate a new one. When the source is lost, we have not really lost it either, because it is on every machine that has the repo.

What the other tools cannot do

I want to address the alternatives directly.

Figma's version history is excellent for static design. It is a snapshot system. It does not produce diffs. You cannot branch a Figma file in a way that allows merge. You cannot review a Figma change as a pull request. The history is a list of named snapshots, not a graph of commits.

Frame.io's review system is excellent for client review. You upload an MP4 and stakeholders comment with frame-level timestamps. It is a great commenting tool. It is not version control. The artifact under review is an export, not the source. When the client says "go back to the version from Tuesday," somebody has to find Tuesday's project file.

Abstract (now defunct) tried to be git-for-Sketch and almost made it. The hard problem they did not solve was three-way merge of binary Sketch files. The XML-extracted diffs they showed in review were a hint of what was possible but not a complete answer. The tool died, in part, because the artifact format never gave them the leverage they needed. (For a longer take on the timeline-tool gap, see the After Effects comparison.)

The reason these tools cannot do what git does is that their artifact is not text. The artifact decides what the version control system can do. HyperFrames bet that the right artifact is HTML. The bet pays off here.

What this changes about hiring and onboarding

A side effect I did not predict. When I joined this team, my onboarding took half a day. I cloned the repo. I read the README. I ran npx hyperframes init. I read one composition end-to-end. I started shipping that afternoon.

Compare to the onboarding for a motion design team. New designer arrives. Someone walks them through the project file conventions. They ask where the brand kit lives. They are told "DM Sarah, she has the latest version." They poke at AE for two days before they ship anything. Three weeks in, they still find files that follow conventions nobody remembers establishing.

When the work is in a repo, the work documents itself. The README is the team's wisdom, version-controlled. The compositions are the examples, all readable. The conventions are linted. A new hire reads the codebase the way they would read any codebase, and they ramp at the speed they would ramp on any codebase.

This is, structurally, the same thing that happened to web development between 2008 and 2015. Static site generators, npm, git workflows — these did not change what web developers shipped, but they changed who could ship it and how fast. Motion design is having that moment.

How to start

If you are convinced and want to try this on a real project, here is a minimum viable workflow.

Create a git repo. Add compositions/ as a directory. Put one HTML file in it. Write a Makefile (or package.json scripts) with render and preview targets. Add a brand.css for tokens. Commit. From now on, every change to the composition is a commit. Every variant is a branch. Every render writes a sidecar with the commit hash. Every review is a pull request.

This is not new infrastructure. It is the same infrastructure your software team has been using since 2010. The only change is that the artifact under management is now also a motion design. That is the unlock.

Open a terminal. git init. Begin.