Git for Product Managers — A Beginner's Guide
You don't need to be an engineer to use Git. If you can save a file, you can use version control. Here's everything you need to know to start collaborating on code — or shipping your own projects with AI tools.
What is Git?
Git is a version control system. Think of it as "Track Changes" for code — except it works across entire projects, not just single documents. Every change you make is saved as a snapshot called a commit. You can go back to any previous snapshot at any time.
Why should you care? If you're building anything with AI coding tools like Claude Code or Cursor, Git is how you save your work, undo mistakes, and deploy to production. It's also how every engineering team you work with manages their code — so understanding it makes you a better collaborator.
5 Commands You'll Use Every Day
1. git status
Shows you what's changed since your last commit. Think of it as asking "what did I change?" Run this before every commit to make sure you're saving what you think you're saving.
git status
2. git add
Stages your changes — tells Git "I want to include these files in my next snapshot." You can add specific files or everything at once.
git add index.html # add one file
git add . # add everything
3. git commit
Takes the snapshot. Every commit needs a message describing what you changed and why. Good messages help you (and your team) understand the project history.
git commit -m "Add pricing page with founding member CTA"
4. git push
Uploads your commits to GitHub (or another remote). This is how you deploy to production, back up your work, and share with collaborators.
git push
5. git pull
Downloads the latest changes from the remote. If you're working with a team (or switching between computers), always pull before you start working.
git pull
Your First GitHub Repository
A repository (or "repo") is a project folder tracked by Git. GitHub is where repos live online. Here's how to create your first one:
- Go to github.com and create a free account if you don't have one.
- Click the green "New" button on your dashboard.
- Name your repo (e.g.,
my-first-project), add a README, and click "Create repository." - Clone it to your computer:
git clone https://github.com/your-username/my-first-project.git - Make changes, then run:
git add . && git commit -m "First commit" && git push
That's it. You now have a project on GitHub. When you connect this to a platform like Vercel, every push automatically deploys your site.
Branching Basics
Branches let you work on new features without breaking what already works. Think of it as making a copy of your document to experiment on — if the experiment works, you merge it back. If it doesn't, you delete the branch and nothing is lost.
git checkout -b new-feature # create and switch to a new branch
# ... make your changes ...
git add . && git commit -m "Add new feature"
git push -u origin new-feature # push the branch to GitHub
On GitHub, you'll create a Pull Request (PR) to merge your branch back into main. This is how teams review code before it goes live — and it's a great habit even when you're working solo.
3 Mistakes Everyone Makes (And How to Fix Them)
1. Committing sensitive data
Never commit passwords, API keys, or .env files. Add a .gitignore file to your project that excludes sensitive files. If you accidentally commit a secret, rotate the key immediately — Git history is permanent.
2. Giant commits with vague messages
"Updated stuff" doesn't help anyone. Commit small, commit often. Each commit should do one thing, and the message should say what and why.
Good: "Fix mobile nav overlap on pricing page"
Bad: "changes"
3. Never pulling before pushing
If you and a teammate both edit the same file, you'll get a merge conflict. The fix: always git pull before you start working, and before you push. Most conflicts are trivial to resolve — Git shows you both versions and you pick which to keep.
Next in the Git track: Git 102: Working with Engineering Teams →