Maintaining a converted Framer site with Git

The cleanest way to maintain a Framer site converted with Deframer is to treat it like any other Next.js App Router project: initialize a Git repository, commit the untouched conversion first, make every change on a branch, and review it before it ships. If the site is still edited in Framer, keep the converter's output on its own branch, convert again after each Framer republish, and merge that branch into your work so Git shows exactly what changed. The project already ships with a .gitignore and a TypeScript setup, so you can start in a few commands.

Step 1: Initialize the repository

Unzip the download, install dependencies and confirm it runs before your first commit. Next.js 16 needs Node.js 20.9 or later.

unzip my-site.zip
cd my-site          # the unzipped project folder
npm install
npm run build
git init
git add .
git commit -m "Initial conversion from Deframer"

Running npm install creates a package-lock.json. Commit it: package.json pins exact versions of next, react, react-dom, motion and the site's own packages, and the lockfile pins everything they depend on, so every machine and every deployment installs the same tree.

What the included .gitignore covers

The converted project's .gitignore already lists:

node_modules
.next
out
next-env.d.ts
*.tsbuildinfo
.env*.local

That keeps build output and dependencies out of history, and keeps .env.local (where form webhook URLs go) out of the repository. .env.example is committed on purpose: it documents which variables the project reads, such as FORMS_WEBHOOK_URL, without their values.

Why the first commit should be untouched

Resist the urge to tidy before committing. A pristine first commit is your reference point: when something looks wrong later, git diff against it tells you whether the converter produced it or someone changed it. It also makes the re-conversion workflow below possible.

Step 2: Push and connect your host

Create an empty repository on your Git host, add it as a remote and push:

git branch -M main
git remote add origin <your-repository-url>
git push -u origin main

Most Next.js hosts can deploy straight from a Git repository, building main for production and creating preview deployments for other branches or pull requests. The exact behavior and settings differ, so check the provider's docs; deploying to Vercel, Netlify, Cloudflare or Fly.io covers the per-host setup.

Step 3: Work on branches

A simple routine works for most teams:

1. git switch -c fix-pricing-copy
2. Edit. The project README's "Where to edit" table points you to the right file: page content in src/views/, shared pieces in src/components/, CMS records in src/cms/<collection>.json, colors in src/styles/tokens.ts.
3. npm run build locally to catch errors early.
4. Commit, push, open a pull request, and check the preview deployment at desktop, tablet and phone widths.
5. Merge to main to ship.

Small, focused commits pay off here. "Update hero headline" and "Add new case study" are easy to review and easy to revert. A single commit mixing copy, layout and a dependency bump is not.

Type checking in pull requests

If the site has Framer code components, next.config.ts keeps typescript: { ignoreBuildErrors: true } with a comment explaining why: that code was written in Framer's editor, which never type-checks it. npx tsc --noEmit still reports everything. A useful habit is to run it on each branch and make sure you haven't added new errors in files you touched, even if older ones remain in src/code/ or src/vendor/.

Step 4: Re-converting after a Framer republish

Some teams keep designing in Framer and use the converted project as the production codebase. When the Framer site changes, you need those changes in the project without losing your own edits. A dedicated branch for converter output handles this.

Set up the branch once

Right after the initial commit, before any edits of your own:

git branch deframer

The deframer branch only ever holds unmodified conversions. main holds your work.

Each time the Framer site is republished

1. Convert the site again in Deframer. Converting is free; a republished site makes a new project, and downloading it uses a credit (see how credits work).
2. Check the result page's notices before downloading.
3. Replace the branch's contents with the new conversion:

git switch deframer
git rm -rq .                         # stage removal of every tracked file
unzip -o ~/Downloads/my-site.zip -d /tmp/new-conversion
cp -R /tmp/new-conversion/my-site/. .
npm install                          # regenerate package-lock.json for this conversion
git add -A
git commit -m "Conversion after Framer republish"

Removing everything first matters: it lets Git record files the new conversion no longer contains, such as a deleted page. Running npm install before committing keeps a lockfile on the branch, so the merge doesn't delete yours. Adjust the folder names to match your zip.

4. Review what Framer changed: git diff HEAD~1 --stat, then look at individual files.
5. Bring it into your work:

git switch main
git switch -c merge-conversion
git merge deframer

Git applies the converter's changes on top of yours. Where both sides edited the same lines, you resolve the conflict by hand, then build, test and open a pull request as usual.

Expect the first few merges to need attention. Changes in Framer can ripple through generated files, especially CSS modules and shared components, so conflicts tend to cluster where you've made your heaviest edits. Keeping your own changes in separate files where you can (a new component instead of rewriting a generated one) makes these merges smaller.

When to stop re-converting

At some point the code becomes the source of truth and Framer becomes a sketchpad. Once your edits outweigh what you'd pull in, it's usually simpler to make design changes directly in the code and retire the deframer branch. There's no wrong time; pick it deliberately.

Step 5: Keeping dependencies current

Pinned versions mean nothing changes under you, but it also means updates are your job.

npm outdated

A careful order:

1. Patch releases of next, react and react-dom first, together. Build and click through the site.
2. motion next, then check animations, hover states and page transitions in the browser.
3. The site's own packages one at a time, testing the components that use them.
4. Major versions on their own branch, after reading the package's upgrade guide.

Run npm audit periodically, and update @types/react, @types/node and typescript alongside the packages they describe. If a build fails after an update, common conversion issues explains several of the errors you may see, and the agency workflow guide covers keeping one repository per client.