Guides / Prompting and shipping

How to Use Git with an AI-Built App

Use Git with an app built by AI: commit after each working change, write clear messages, branch for risky work and undo safely when the AI breaks something.

Mythex Team · 2026-09-29 · 5 min read

To use Git with an AI-built app, connect the project to a Git repository, commit after every change that works, write a one-line message saying what changed, and keep secrets out with a .gitignore. Use a branch for anything risky, pull before you prompt again if someone else changed the code, and when the AI breaks something, go back to the last good commit instead of prompting on top of the mess.

Git is version control: a history of every saved version of your code. GitHub is a website that stores Git repositories online. If those are new, start with what GitHub is. This guide is about the habits that make Git useful when an AI is writing most of the code.

Why Git matters more with AI

An AI can change twenty files in one turn. That's fast, and it also means one prompt can quietly break something you tested yesterday. Git gives you:

• A way back. Any committed version can be restored.
• A record of what changed. You can see exactly which files and lines a prompt touched.
• A copy outside the builder. Your code lives somewhere you control.
• A standard handoff. Any developer, host or tool can work from a Git repository.

Step 1: Connect a repository

Create a repository (usually private) on GitHub or a similar service, and connect your project to it. Most AI app builders that support Git do this through a settings page with a "Connect GitHub" button. If yours doesn't, you can export the code and push it yourself, or ask a developer to set it up once.

Before the first push, make sure the repository ignores things that shouldn't be in it:

Check the .gitignore file. Make sure it excludes .env files, node_modules, build output folders and any file containing secrets. Tell me what you added.

Step 2: Commit after every working change

A commit is a saved snapshot with a message. The habit that matters: commit when something works, before you ask for the next thing.

1. Prompt for one change.
2. Check it in the preview.
3. If it works, commit (or sync) with a message.
4. Then move on.

Small commits mean that when something breaks, you know which change did it, and undoing it doesn't throw away other work.

Step 3: Write messages you can read later

A good message says what changed and why, in one line:

• Good: Add CSV export to the orders page
• Good: Fix booking form rejecting times after 6pm
• Not useful: update, changes, fix stuff

You can ask the AI to write them:

Summarise the changes since the last commit in one line, starting with a verb, under 70 characters.

Step 4: Use branches for risky work

A branch is a separate line of work. You can try something on a branch, and if it doesn't work out, abandon it without touching the main version.

Use a branch when:

• The change is large (a redesign, a new payment flow, a database change).
• Someone else is working on the same app.
• You want someone to review the change before it goes live.

When the work is done and tested, it gets merged back into the main branch. On GitHub, that usually happens through a pull request, a page showing the changes for review. If your builder only syncs one branch, a developer can manage branches on the GitHub side.

Step 5: Undo safely

When a prompt breaks the app, resist the urge to prompt five more times on top of it. Go back to the last good version and try a clearer prompt.

• In the builder: use its checkpoint or restore feature, if it has one.
• In Git: git revert creates a new commit that undoes an old one, keeping history intact. It's the safe choice for code others may have pulled.
• Avoid git push --force on a shared branch unless you know exactly why. It rewrites history for everyone.

If you're unsure, ask:

The last change broke the login page. Show me which files it changed compared with the previous commit, and explain what each change did. Don't change anything yet.

Step 6: Pull before you prompt

If a developer or another tool changes the code on GitHub, the AI builder doesn't know until you pull those changes in. Prompting on old code causes conflicts and lost work.

• Pull at the start of every session.
• Agree who edits what, and avoid both sides editing the same files at once.
• If you get a merge conflict (two changes to the same lines), ask the developer or the AI to resolve it and explain the choice.

Example prompts

Before we start: what changed in the repository since my last session? Summarise the commits.

Make the next change on its own: add a "Duplicate" button to each invoice. Don't change anything else, so I can commit it separately.

Check that no API keys, passwords or .env files are tracked in Git, including in past commits. Report file names only, not values.

Common mistakes

• Committing secrets. Once a key is in Git history it's exposed, even after you delete the file. Rotate it.
• One giant commit a week. You can't undo one change without undoing all of them.
• Messages like "update". History becomes useless for finding what broke.
• Prompting on stale code. Pull first when someone else is editing.
• Force-pushing to fix a mistake. It can erase other people's work. Revert instead.
• Committing node_modules. It's huge and gets recreated from the lock file anyway.

Checklist

• The project is connected to a private repository.
• .gitignore excludes .env, node_modules, build output and secrets.
• I commit after each change that works.
• Commit messages say what changed in one line.
• Large or risky changes go on a branch and get reviewed.
• I pull before prompting when someone else edits the code.
• I undo with checkpoints or git revert, not force-push.
• Any key that was ever committed has been rotated.

Git on Mythex

Mythex saves a git checkpoint after every successful agent turn, and Revert to this point rolls the project back to it — the builder-side undo described in step 5. See Iterate without rebuilding.

On Pro, GitHub sync connects a repository from project settings so you can push and pull against it, and export downloads the project with secrets and node_modules left out. See GitHub, export, and import. Connecting GitHub before handing a project to a developer makes the handoff much simpler — see how to work with a developer on an AI-built app and how to export and self-host an AI-built app.