Git for product managers: a plain-language guide

Git for product managers comes down to one skill: you need to read a repository on GitHub well enough to answer "what shipped, when and why" yourself, and you never have to type a command. Git records every change to the product as a step with an author, a date and a note. GitHub shows that record in a browser. Once you know your way around a handful of pages, you stop waiting for a developer to answer questions the history already answers, and the questions you still ask become short and precise. The same goes for marketers whose site copy lives in the repository.

A quick case: did the checkout fix go out?

CatChow, an online pet-food shop, raised its free-delivery threshold from 800 to 1000 UAH. The checkout page still says "Free delivery from 800 UAH", and confused customers write to support. On Monday Sofia, the product manager, asks Daniel, a web developer, to fix the text. On Thursday support asks her whether it is fixed, because the site still shows the old number.

The usual move is to message Daniel and wait. Sofia opens the catchow/website repository instead:

Find the file. She searches the repository for the phrase "Free delivery from" and lands in pages/checkout.html.
Open its history. The History button on the file lists every commit that changed it, newest first. At the top: "Fix free delivery threshold on checkout (#142)", by Daniel, two days ago.
Read the change. The commit page shows exactly what was replaced (the block below).
Follow the link. #142 leads to the pull request. It is marked as merged into main, the branch that holds the accepted version of the site.
Check the release. CatChow puts the site live from tagged releases. The latest one, v2.4.0, was published last Friday, before the fix existed.

- <p class="hint">Free delivery from 800 UAH</p>
+ <p class="hint">Free delivery from 1000 UAH</p>

So the text is fixed in the code but has not reached the site. Sofia answers support within minutes: "Fixed, it goes live with the next release." Her message to Daniel is no longer "any news on the checkout text?" but "#142 is merged and isn't in v2.4.0. When does the next release go out?" He replies in one line: Friday morning, v2.4.1.

Six terms in plain language

Term	What it is	What it tells you as a PM
Repository	The project folder together with the full history of its changes	One place for the current product and its past
Commit	One saved step: the change, its author, date, message and unique id (hash)	Who changed what, and when
Branch	A parallel line of commits where work happens without touching `main`	Work in progress that customers can't see yet
Pull request	A page that proposes merging a branch, with a description, review and automated checks	The discussion and the reason behind a change
Merge	Combining the commits of one branch into another, usually into `main`	The change is accepted, though not necessarily live
Tag and release	A tag is a permanent name on one commit, such as `v2.4.0`; a release is a page with notes on the tag	Which changes are in which version

One more word sits outside Git: deploy, putting a version onto the live servers. Git doesn't record whether a change is deployed. Some teams deploy automatically after every merge into main, others on a schedule or from release tags. Ask your developers once how it works in your team, because every answer to "is it live?" depends on it.

How to read a repository page

Read it top to bottom. GitHub moves buttons around now and then, but the parts stay the same.

Name and tabs. Code shows the files, Issues holds bugs and tasks, Pull requests holds proposed changes.
Branch selector. It usually shows main. The files below always belong to the selected branch, so check it before you conclude anything.
Latest commit. Author, message, a short hash and how long ago it happened. The commit counter next to it opens the full history.
File list. Each row shows the message of the last commit that touched that file or folder, and when.
README. The team's own introduction to the project, shown under the file list.

The free lesson Repository and commits: reading a repo page walks through each part on the CatChow repository.

What a commit message and a diff tell you

The commit history is a list of messages, newest first. A good message starts with a short summary written like an instruction ("Fix", "Add", "Raise") and, when the reason isn't obvious, adds a sentence on why. Compare two messages for the same change:

fix
Fix free delivery threshold on checkout, followed by "Threshold is 1000 UAH now; checkout still showed 800. (#142)"

The first one makes you open the commit and guess. The second answers the question straight from the list. You have a hand in this: the reason you give in a request is what ends up in the message and the pull request.

A diff shows what changed between two versions. Removed lines are red with a minus, added lines are green with a plus, and the unmarked lines around them are context. An edited line appears as one removed line and one added line, as in Sofia's case. You don't have to understand code to read a copy or price change: look for the words and numbers you know.

The diff says what changed; only the message and the pull request can say why. The lesson Reading history: messages, diffs and blame lets you practise both.

Five everyday questions and where the answer lives

Question	Where to look
Is my fix live?	The pull request: is it merged? Then the release or deployment that came after it
What changed in this release?	The release notes for that version, or a comparison of two tags, which lists the commits in between
Who changed this text, and why?	The file in `Blame` view, which shows the last commit for each line, then that commit's pull request
What is the team working on now?	The open pull requests and the branches with recent activity
Why did this behaviour change last week?	The history of the file involved, or the commit history of `main` narrowed to those dates

What you don't need to learn

The command line. Developers type git commit or git log in a terminal. Everything you need to read is in the browser.
Rebasing, squashing and resolving conflicts. It's enough to know that a merge conflict means two branches changed the same lines and a person has to choose the result, which can delay a merge.
Branching models in depth. Learn your own team's route from a branch to production and stop there.
Reading code. Commit messages, pull request descriptions, copy and numbers in a diff cover most PM questions.

Common mistakes

Treating "merged" as "live". Merged means accepted into main. Whether customers see it depends on the deploy.

Reading blame as the full story. Blame shows the last commit that touched a line, and that commit may only have reformatted the file. If the message says nothing about your question, look one step further back in the file's history.

Counting commits as productivity. The number of commits or changed lines says nothing about the value delivered.

Confusing "shipped" with "worked". The repository tells you what went out. Whether customers behave differently is a separate question for analytics, the one behind outcome vs output.

Etiquette: don't use blame to blame

Blame answers "where did this line come from?", not "whose fault is it?". Developers run it on their own code all the time.
Ask with a link and about the reason: "What was the thinking behind #142?" works better than "Why did you change the checkout?"
Don't paste someone's commit into a public channel with "who broke this?". Undoing a bad change is routine; repairing trust takes longer.
In a pull request, comment on what you know: copy, prices, what the customer will see. Leave code style to the reviewers.

What to do this week

Get read access to your product's repository.
Ask a developer how a merged change reaches production and where you can see that it did.
Take one change you asked for recently and trace it: file, history, commit, pull request, release.
Set Watch on the repository to releases only to hear about each new version.

Key takeaways

Reading a repository is safe and needs no command line.
Six terms cover most conversations: repository, commit, branch, pull request, merge, tag and release.
A commit says what changed and when; the pull request says why and who agreed.
Merged is not live. Learn how your team deploys.
Use blame to find the reason, never the culprit.

FAQ

Do product managers need to learn Git commands?

No. Commands are for people who change code on their own computers. A PM mostly reads files, history, pull requests and releases, and all of that is available in the GitHub web interface.

What is the difference between Git and GitHub?

Git is the version control system that records the history as commits. GitHub is a website that hosts Git repositories and adds teamwork tools on top: pull requests, reviews, issues and releases.

Can I break something by looking around a repository?

No. Viewing changes nothing. The product changes only when someone merges a change and it gets deployed, and most teams require a review before that.

How do I know whether a merged change is live?

It depends on how your team deploys. If every merge into main is deployed automatically, a merged pull request usually means the change is live soon after. If the team ships tagged releases, check whether the latest release was made after your change was merged. Then confirm on the product itself.

Learn it hands-on

The free lesson Why teams keep history: version control without fear starts from zero on the CatChow website repository, with quizzes and a practice task checked by AI. It opens the free course Git and GitHub for Product People.

Git for product managers: read the repository, skip the command line