LaunchWithCursor

Knowledgebase

MissionWorkflowInstallUpdatesPromptsGitEnv varsDeployHandoffTesting
Knowledgebase12 min read

Git & GitHub

What Git and GitHub are, how to sign up, staging vs production branches, and the few commands you should recognize.

If you are building with AI, you still need a safe place to store your code and a way to ship updates without breaking production. Git and GitHub are the industry standard for that — and LaunchWithCursor connects to GitHub when you deploy.

This guide is written for founders who are not engineers yet. You do not need to memorize everything here; your AI coding assistant can run most commands for you once you understand the ideas.

What is Git?

Git is version control for your project folder. Think of it as a timeline of save points for your code:

  • Every time you commit, you label a snapshot of your project (“added login page”, “fixed checkout bug”).
  • You can always go back to an earlier snapshot if something breaks.
  • Git runs on your computer (inside VS Code, Cursor, or Terminal). It tracks what changed in your project files.

Git does not require the internet by itself. It works on your laptop first.

What is GitHub?

GitHub is a website that hosts your Git history in the cloud — like Google Drive, but designed for code.

  • A project on GitHub is called a repository (most people shorten this to repo).
  • You push commits from your computer to GitHub so your team (and LaunchWithCursor) can access the latest code.
  • You pull when you want to download changes someone else made.

LaunchWithCursor deploys by cloning your GitHub repo on each build. No GitHub repo → no automated deploy from your latest code.

Why this matters: Saving code only on one laptop is risky. GitHub is the shared source of truth your dashboard, collaborators, and deploy pipeline all read from.

Create a GitHub account (step by step)

  1. Open github.com and click Sign up.
  2. Enter your email, choose a password, and pick a username (this appears in URLs like github.com/yourname).
  3. Verify your email when GitHub sends the confirmation link.
  4. Skip optional surveys if you want — they are not required to use GitHub.
  5. Optionally enable two-factor authentication (Settings → Password and authentication) for extra security.

You do not need a paid GitHub plan to start. The free tier is enough for private repos and collaborators.

Connect GitHub to LaunchWithCursor

After your account exists:

  1. Sign in to the LaunchWithCursor dashboard.
  2. Open Settings → Connections and link your GitHub account (or sign in with GitHub if you used that at registration).
  3. On Deploy → Overview, choose the repository that contains your project.

For org repos or handoffs, see the GitHub access section in Deploy & hosting.

Branches: Staging and Production

A branch is a separate line of development inside the same repo — like a draft copy vs the live copy.

LaunchWithCursor cares most about two branches:

BranchTypical namePurpose
Stagingstaging, develop, or main while you are still testingSafe place to try features before real users see them. Point your staging deploy at this branch.
Productionmain or productionThe code that powers your live app for customers. Only merge here when staging looks good.

Some teams use a third branch (for example dev for experiments). That is fine — but you still want a clear “not live yet” branch and a “live” branch. On the dashboard, set which Git branch each deploy uses on Deploy → Overview.

Why this matters: Editing production directly is how founders accidentally ship half-finished features. Staging lets you click through the app on a test URL before you promote the same commit to production.

Git commands every Builder should recognize

You rarely need to type these yourself — ask your AI assistant to run them — but knowing the names helps you follow along:

CommandPlain English
git status“What changed since my last commit?”
git add .“Stage all my changes for the next snapshot.”
git commit -m "message"“Save a snapshot with a short note.”
git push“Upload my commits to GitHub.”
git pull“Download the latest commits from GitHub.”
git checkout -b staging“Create and switch to a new branch called staging.”
git merge staging“Bring staging’s changes into my current branch.” (Often used before production releases.)

If you need something else — revert a file, resolve a conflict, tag a release — ask your AI coding assistant in Cursor or VS Code. Paste the error message if Git complains; that is normal even for experienced developers.

What to commit vs what to keep private

Do commit to GitHub:

  • Your application source code
  • .env.example (lists variable names, not real secrets — see Environment variables)
  • .launchwithcursor/pack/ and root AGENTS.md after installing the extension

Do not commit:

  • .env (real passwords and API keys)
  • node_modules/ and build output (your .gitignore should exclude these)

Your AI assistant should maintain a .gitignore file so secrets and junk folders stay out of the repo.

Typical workflow with LaunchWithCursor

  1. Build or fix something locally with your AI assistant.
  2. git commit + git push to your staging branch.
  3. Deploy staging on LaunchWithCursor and click through the app.
  4. When happy, merge to production and deploy production.
  5. Run LaunchWithCursor: Run Full Scan in the editor after meaningful repo changes so the dashboard stays in sync.

For org or handoff access issues, see Transfer ownership.

Next steps