# What is Git? A plain-language guide for product managers

> What is Git, in plain words for product managers: what it does, Git vs GitHub, the basic terms, and how to check what shipped, when and why.

- Source: https://productovi.com/blog/git-for-product-managers
- By: Sergey Bruh
- Published: 2026-10-02
- Topics: Version control: why teams keep history, Repositories and commits, Reading history: messages, diffs, blame

What is Git? **Git is a free version control system: it records every change to a project's files as a saved step with an author, a date and a short note, so a team can see the full history, work on several things in parallel and undo a mistake in minutes.** Almost every software team uses it, which means the whole story of your product (what changed, when, by whom and why) is already written down. For a product manager or a marketer that is the useful part: you don't need to type a single command, but if you can read that history in a browser, you can answer "did my fix ship?" yourself instead of waiting for a developer.

## What does Git do?

Git solves four problems that every team changing the same product runs into.

- **History.** Each saved step, called a commit, keeps the change itself and the context around it. Months later you can still see why the delivery threshold changed or who rewrote the pricing page.
- **Parallel work.** Developers work on separate branches, so a half-finished feature doesn't break the version customers use.
- **Safe undo.** Any earlier state can be restored. A bad change is reverted with one new commit, and nothing in the history is lost.
- **Collaboration.** Everyone has a full copy of the project and its history, and Git combines their work when it is ready.

Git was created in 2005 for the Linux kernel, one of the largest open-source projects, and has since become the default tool for code. Teams also use it for anything that lives in text files: website copy, documentation, configuration and translations.

## Git vs GitHub: what's the difference?

**Git** is the tool that records the history. It runs on each developer's computer and has no website of its own.

**GitHub** is a website that hosts Git repositories and adds teamwork on top: pull requests, code review, issues, releases and project boards. GitLab and Bitbucket do the same job; your team uses one of them.

The split matters to you because almost everything a PM needs lives on the hosting site. You read history, changes and releases in the browser, while developers run Git itself in a terminal. When someone says "check it in Git", they almost always mean "check it on GitHub".

## Git basics: 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 a change travels: from branch to release

Put the six terms together and you get the route almost every change takes:

1. A developer creates a **branch** from `main`, for example `fix/checkout-text`.
2. They save the work as one or more **commits** on that branch.
3. They open a **pull request** that describes the change; teammates review it and automated checks run.
4. The pull request is **merged** into `main`.
5. The team ships it: right after the merge, or later as part of a tagged **release**.

Teams differ mostly in steps 1 and 5: how long branches live and how often `main` goes live. [GitHub flow vs git flow](/blog/github-flow-vs-git-flow) compares the two common branching models, [trunk-based development](/blog/trunk-based-development) covers teams that merge into `main` every day, and [semantic versioning explained](/blog/semantic-versioning-explained) shows how to read release numbers such as `v2.4.1`.

## 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:

1. **Find the file.** She searches the repository for the phrase "Free delivery from" and lands in `pages/checkout.html`.
2. **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.
3. **Read the change.** The commit page shows exactly what was replaced (the block below).
4. **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.
5. **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.

```diff
- <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`.

![The checkout fix was committed on a branch and merged into main as #142, but the live site keeps showing 800 UAH from release v2.4.0 until v2.4.1 is deployed](/blog/git-for-product-managers/diagram.png)

## 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](/courses/git-for-product/reading-a-repository-page/theory) 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](/courses/git-for-product/reading-history-diffs-and-blame/theory) lets you practise both.

## What do product managers use Git for?

Mostly for answering five everyday questions without interrupting anyone:

| 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            |

The second use is taking part in review. You don't judge the code, but you can check the copy, prices and screenshots in a pull request before it is merged; [how to review a pull request](/blog/how-to-review-a-pull-request) shows what to comment on.

## Do you need to learn Git commands?

For reading, no. Here is what you can safely skip:

- **The command line.** Developers type `git commit` or `git log` in a terminal. Everything you need to read is in the browser. If you're curious what the commands in your team's chat mean, the [Git cheat sheet](/tools/git-cheat-sheet) explains the common ones in plain words.
- **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](/blog/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.

## Where to start this week

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

## Key takeaways

- Git is a version control system that keeps the full history of a product's files; GitHub is the website where your team shares and discusses that history.
- 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.
- Reading a repository is safe and needs no command line; use blame to find the reason, never the culprit.

## FAQ

### What is Git in simple terms?

Git is a tool that saves every version of a project's files, together with who changed what, when and why. Think of it as a detailed, permanent "track changes" for a whole product that many people can edit in parallel without overwriting each other's work.

### Is Git hard to learn for beginners?

Reading Git history is easy: with the six terms above, a beginner can follow a change on GitHub in an afternoon. Writing changes from the command line takes longer, but most product managers and marketers never need it.

### 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.

### 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](/courses/git-for-product/why-teams-keep-history/theory) starts from zero on the CatChow website repository, with quizzes and a practice task checked by AI. Next comes [Branches: parallel versions of the project](/courses/git-for-product/branches/theory), and the whole path is the free course [Git and GitHub for Product People](/courses/git-for-product).

## Related lessons

- [Why teams keep history: version control without fear](https://productovi.com/courses/git-for-product/why-teams-keep-history.md)
- [Repository and commits: reading a GitHub repo page](https://productovi.com/courses/git-for-product/reading-a-repository-page.md)
- [Reading history: messages, diffs and blame](https://productovi.com/courses/git-for-product/reading-history-diffs-and-blame.md)
- [Git branches: parallel versions of the project](https://productovi.com/courses/git-for-product/branches.md)
- [What is a pull request? Anatomy of a PR page](https://productovi.com/courses/git-for-product/pull-request-anatomy.md)