Git is the tool teams use to work on the same code without overwriting each other's work.
Your computer vs the shared server. Your own computer holds your private copy. Anything you do there (including a live preview at localhost) is yours alone until you push it up to the shared server. The shared server (GitHub or GitLab) is what the whole team sees. Keep the two apart in your head and most of what follows makes sense.
The words you'll hear
- Repo — the shared folder of code your team works in, hosted on GitHub or GitLab.
- Clone — make a copy of the repo on your own computer.
- Branch — your own private version of the code, so nothing you do touches the shared version until it's reviewed.
- Commit — save a checkpoint of your work. Commit often; it's what lets you undo mistakes.
- Push — upload your branch to the shared server so others can see it. Not merged yet, just uploaded.
- Pull request (PR) on GitHub, merge request (MR) on GitLab — two names for the same thing: asking for your branch to be reviewed and added into the shared code. This guide says pull request for both.
- Merge — approved and added in. Your work is now part of the shared code.
That's the whole vocabulary. Your AI can run all of these for you; knowing what they mean lets you tell when something looks off.
Gitty, your git companion
You don't have to memorise any of this. Gitty is a companion in Claude Code that runs the git steps with you, one at a time. It explains each word as it comes up, and checks with you before anything leaves your computer.
Type /dx-harness:dx-design-git, then say what you want in plain words:
- "start me on a new feature"
- "save my work"
- "put this up for review"
- "what's a merge conflict?"
- "I think I broke something"
Gitty works out the git and walks you through it. It ships inside the design harness — install that and Gitty comes with it.
Run /dx-harness:dx-design-git whenever you want a hand. If you're not on the
harness, it's also public at tashayip/git-buddy.
Good habits
A few habits keep you safe and make your work easy to follow:
- Pull the latest first. Before you start, grab everyone's newest changes so you're not building on an old version.
- Work on a branch, never on
main. Your branch is a safe copy;mainstays stable for the whole team. - Commit small and often. Save little checkpoints as you go, not one big dump at the end — small commits are easy to undo.
- Write clear commit messages. One line saying what changed, so a teammate gets it without opening the files.
- Mistakes are recoverable. Git almost never loses work; nearly anything can be recovered, so a confusing moment is rarely a real problem.
The everyday rhythm
Once you're set up, most days follow the same shape:
- Pull the latest
mainso you start current. - Branch off it for your change.
- Build, committing small checkpoints as you go.
- Push your branch up.
- Open a pull request and get it reviewed.
- Once approved, it's merged in.
Step 3: Build and Step 4: Ship walk through each of these.