Git Without the Fear: The Only 5 Actions a PM Needs
5 min readPublished By Ofer Regev
Designers push assets. Developers push code. Decisions become reality in the repo, and if you've never opened it, you're always hearing about changes second-hand.
Git has a reputation for being scary. It doesn't need to be. For a PM, the useful part is small.
Why bother
Being comfortable in the repo lets you:
See what changed before it reaches production.
Make small fixes (a copy change, a typo) without waiting for a developer.
Review a change and understand its scope in two minutes.
Stay in the loop when designers and devs push work.
Three tools, one workflow
Tool
Role
What it does
Git
The engine
Runs on your machine and tracks every change and version
GitHub
The cloud
Where the team shares, reviews and merges work. The single source of truth
Cursor, VS Code or Antigravity
The dashboard
A visual interface to Git. No terminal, just point and click
The five actions
Commit. Save a snapshot of your changes. "Updated copy on the onboarding screen."
Push. Send your commits up to GitHub so the whole team can see them.
Pull. Get the latest changes from GitHub. "Designer pushed new assets, pulling to sync."
Branch. Create a safe parallel copy to work on. "Testing a flow without touching main."
Pull request (PR). Ask the team to review and merge your branch.
That's the whole vocabulary you need to start. Git tracks every change, so nothing is ever truly lost.
Your editor is the dashboard
In Cursor (VS Code is nearly identical):
Branch selector: bottom-left corner. Click to switch or create a branch.
Source Control panel: open it with Ctrl+Shift+G to see every changed file in real time.
Stage your changes: click the + next to the files you want in your commit.
Write a commit message: one clear sentence, like "Fixed CTA copy on pricing page."
Commit, then sync/push. The snapshot is saved locally and then synced to GitHub.
Branches are your safety net
A branch is a parallel copy of the project. main stays untouched while you work. Name it clearly: fix/onboarding-copy or review/designer-assets.
Create one when you're:
Updating copy or content on any page.
Testing a new user flow before it goes live.
Reviewing a designer's changes in isolation.
When you're done, open a pull request to merge back safely.
Real PM scenarios
A designer pushed three new checkout screens. Pull the branch in Cursor. Open Source Control and see exactly what changed. Notice that screen two is missing an error state, and comment on the PR. Async review done in five minutes, no meeting.
Situation
What you do
Designer added new screens
Pull the branch and review the changes
QA found a copy bug
Branch, fix, commit, push
What changed since Monday?
Check the Git history
Why this matters more now
If you're building with AI tools, Git is also your undo button. An agent makes a change you don't like? You roll it back. That's what makes it safe to let AI touch a real codebase.