# The Four Moves Git has dozens of commands. You need four moves, and you never need to memorize the commands behind them, because every move below comes in two versions: - **The clicks:** exactly what to press in GitHub Desktop. - **The prompt:** what to paste into an AI that can touch your project (Claude Code, Cursor, Replit's assistant, Lovable's chat) so it does the move for you. Use whichever you're in. If your app lives entirely in Lovable or Bolt, the tool does Move 1 for you automatically; you mainly need Moves 2-4. Vocabulary used below, one line each: a commit is one saved snapshot of your whole project with a note attached. Push means send your commits up to GitHub. A branch is a parallel copy of the project you can experiment on. Merge means fold a branch's changes back into the real thing. --- ## MOVE 1: SAVE (commit + push) **When:** every time the app is in a state you'd be sad to lose. After every working feature, before you stop for the day, and always BEFORE letting an AI attempt something big. Saving is free and instant; do it more than feels necessary. ### The clicks (GitHub Desktop) 1. Open GitHub Desktop with your project selected (top-left dropdown). 2. The **Changes** tab on the left lists every file that changed since your last save. You don't need to understand the list; leave everything checked. 3. In the **Summary** box at the bottom left, type a one-line message (rule below). 4. Click **Commit to main**. That's the snapshot, saved locally. 5. Click **Push origin** in the top bar. That sends it to GitHub. Not saved-saved until you push. ### The message rule Write what the app can do now that it couldn't before, in plain words, under 10 words. "Login page works", "Fixed the broken checkout button", "Before trying the AI redesign". Never "changes", "stuff", or "asdf". Future-you scrolling the history looking for the last good version will read only these lines. ### The prompt > Save my work: commit everything with a clear one-line message describing what changed since the last commit (look at the actual changes to write it), then push to GitHub. Then confirm the push succeeded and tell me the commit message you used. --- ## MOVE 2: UNDO (go back to a version that worked) **When:** the app is broken, the AI made it worse twice in a row, and you want Tuesday's version back. The key mental shift: you are not deleting the bad version, you are making the old good version the new current version. The bad attempt stays in history too, in case you ever want to look at it. Nothing is destroyed. That's why you can't really break this. ### The clicks (GitHub Desktop) For undoing the most recent save: 1. Open the **History** tab (next to Changes). 2. Right-click the top commit (the bad one) and choose **Revert Changes in Commit**. This creates a new commit that undoes it. 3. Click **Push origin**. Done. For going further back, or if History shows a tangle you don't understand: stop clicking and use the prompt below, or the full recovery prompt in `help-i-broke-it-prompt.md`. Reverting several commits by hand is where non-coders get lost, and the AI genuinely does this better. ### The prompt > My app is broken and I want to go back to a version that worked. Show me the last 10 commits as a numbered list, each with its date and message, in plain English. I'll tell you which number was the last good one. Then restore the project to that version in the safest possible way: do not delete history, do not force anything, create an undo commit instead. Before you run each command, tell me what it does in one sentence and wait for my OK. If things are scarier than "just go back one version" (error messages mentioning conflicts, detached HEAD, or anything you can't parse), use the dedicated recovery prompt in `help-i-broke-it-prompt.md` instead. It's built for exactly that. --- ## MOVE 3: BRANCH (try something risky without breaking the real app) **When:** you're about to attempt something that might wreck things: a redesign, ripping out a feature, "hey AI, rewrite the whole backend". A branch gives you a parallel copy to experiment on while the real app (the main branch, usually literally named `main`) stays untouched. If the experiment works, you merge it into main. If it fails, you delete the branch and main never knew. ### The clicks (GitHub Desktop) 1. Click the **Current Branch** dropdown in the top bar (it says "main"). 2. Click **New Branch**, name it after the experiment (`redesign-attempt`, `new-pricing-page`), click **Create Branch**. 3. Work normally. Every save (Move 1) now lands on this branch instead of main. 4. **It worked?** Current Branch dropdown > **Choose a branch to merge into current branch** while on main (switch back to main first via the same dropdown), pick your branch, click **Create a merge commit**. Then Push origin. 5. **It failed?** Switch back to main via the dropdown. Your app is exactly as you left it. Delete the branch via **Branch menu > Delete** whenever you like. ### The prompt > I want to try something risky: [DESCRIBE THE EXPERIMENT]. Before we start, create a new branch named after this experiment and make sure all current work is committed and pushed on main first, so main is safe no matter what. Do all the experimental work on the branch. When we're done, I'll say either "keep it" (then merge it into main and push) or "abandon it" (then take me back to main exactly as it was and delete the branch). Confirm the setup is done before touching any code. --- ## MOVE 4: SHARE (let a person or an AI see your code) **When:** you want help. A developer friend offers to look, or you want to point an AI tool at your actual codebase instead of describing it from memory. ### The clicks: sharing with a person 1. On github.com, open your repo, click **Settings** (top tab of the repo, not your account settings). 2. Click **Collaborators** in the left sidebar (if it moved, look for "Collaborators and teams" under the Access section). 3. Click **Add people**, type their GitHub username or email, send the invite. They can now see the code and its full history. You can remove them from the same screen later. 4. Read-only alternative: your repo's web address (github.com/you/your-app) is itself shareable. For a private repo only invited people can open it; making it Public (Settings > General > Danger Zone > Change visibility) makes it readable by anyone with the link. ### The clicks: sharing with an AI Most coding AIs connect to GitHub directly. In Claude (claude.ai), look for GitHub under the paperclip/attachments menu or in Settings > Connectors, connect your account, and pick the repo; then ask questions about your actual code. Cursor and Claude Code work on the cloned folder from `github-plain-english.md` section 4, so cloning IS the share. If a tool asks for a "repo URL", that's just your repo's web address. ### The prompt > I've connected you to my repository [OR: the project in this folder]. Before we do anything else, read the codebase and give me a plain-English tour: what this app does, how it's organized, the 5 most important files and what each one is for, and anything that looks fragile or half-finished. Assume I didn't write the code and don't know the vocabulary. No changes yet, just the tour. That prompt is also the best first message of any "help me fix this" session: an AI that has toured the code helps better than one working blind. --- ## The habit, in one line each - **SAVE** constantly. It's the move that makes the other three possible. - **UNDO** without guilt. Going backward is a feature, not a failure. - **BRANCH** before anything scary. Main stays sacred. - **SHARE** early. Code nobody can see is code nobody can help with.