Hi Reader,

Have you ever felt lost while asking your engineers if they have already pulled, pushed, or merged their code? I have 🙋🏻‍♀️ What if I tell you that learning this once and for all will take you only 20 mins? And much more confidence going forward. If you like that, today's issue is for you.

Today in 20 minutes you will:

• Why code repositories matter to PMs (even if you never write code)
• What Git and GitHub are (and why they're not the same thing)
• The 9 words your developers use every day, and what they sound like in standup
• Create your first repo, open a pull request, and merge it
  ​

Why PMs even need to care about code repositories?

Depending on your context you might work less or more with code repos. In my context of small understaffed teams, I had to learn and interact much with it.

Because as a PM you care

→ that all work gets properly stored

→ versions do not get mixed up

→ we can always trace back to what caused an issue in the code

→ if new teammate joins, they are able to understand the software

→ your engineers can work simultaneously

→ and you can also understand what's the current status, next step, and issue when it arises.

And all of these things you care about are done by code repositories like GitHub, which allow you to store your code, do history versioning, and have a code change review process.

Once you can read your repo:

→ You see what actually changed, not just what the ticket said

→ You can use PR descriptions to write release notes

→ You can keep up with AI tools like GitHub Copilot, which can now open pull requests on their own. Someone still decides what gets merged

What's even GitHub (Git, GitLab, etc.)?

Start with the problem these tools solve.

Imagine five engineers changing the same product at the same time.

Without a system, someone overwrites someone else's work. Nobody knows which version is the latest. And when something breaks, nobody can tell what changed.

That's why teams use two things together.

A code repository is one shared place where all the code for a product lives. Plus everything around it, like docs and configuration.

Version control (or history versioning) records every change to that code: what changed, who changed it, when, and why.

Think of Google Docs version history, but for a whole product, and much stricter.

Now the tools. Each one covers part of that job.

Git does the version control. It's the tool that records every change, and it's by far the most common one.

GitHub hosts the repository online, so the whole team works from one shared place. On top of that, it adds what a team needs to work together: reviews, comments, tickets, automation.

GitLab, Bitbucket, and Azure DevOps Repos do the same job as GitHub. Your company might use one of those instead.

The buttons have different names. The concepts are identical. So everything you learn today carries over.

Simple way to think about it:

→ Repository = where the code lives

→ Git = records every change (version control)

→ GitHub (or GitLab, etc.) = the online home for the repo, plus a place for the team to discuss and approve changes

The 9 words your developers use every day

If you've used Google Docs, you already understand most of this.

Repository (repo): The project folder where the code and its full history live.

README: The front page of a repo. A text file explaining what the project is and how to use it. Always the first thing to read.

Branch: Your own copy of the project, so you can work without touching the real thing. Like duplicating a doc before a big rewrite.

Main: The official version. What's on main is what the team treats as the truth.

Commit: A saved change with a short message explaining what changed and why. One entry in version history, with a note attached.

Push: Uploading your commits from your laptop to GitHub so the team can see them. The opposite is pull: downloading the changes others pushed.

Pull request (PR): A request to bring the changes from your branch into main. This is where review happens. Think "suggesting mode": nothing changes until someone accepts.

Merge: Accepting the pull request. The changes become part of main.

Merge conflict: Two people changed the same lines in different ways, and Git can't decide which version wins. A human has to pick.

What this sounds like in standup

The flow your team runs every day:

Branch → Commits → Push → Pull request → Review → Merge → Deploy

Each step has a status you hear about:

→ "I'm working on a branch" = work in progress, nobody else sees it yet

→ "I pushed it" = it's online on a branch, but not in main yet

→ "The PR is open" = done from the developer's side, waiting for review

→ "It's in review" = a teammate is checking it. Comments can send it back

→ "It's merged" = it's in main. But merged doesn't always mean live. Depending on your pipeline, deployment can be a separate step

→ "I have a merge conflict" = someone else changed the same thing. Usually a small delay, sometimes a bigger conversation

Your turn: build your first repo

15 minutes. No code. Everything happens in the browser.

Before you start:

→ Create a free account at github.com if you don't have one

→ Use a personal account, and keep company information out of it

The idea: you'll create a repo for a pretend product, write a short product brief in the README, and then change it the way developers change code.

Branch. Commit. Pull request. Merge.

Step 1: Create a repository

→ In the top right corner, click the + icon, then New repository

→ Name it pm-playground

→ Choose Private (only you can see it)

→ Select "Add a README file"

→ Click Create repository

You now have a repo with one file and one branch: main.

Step 2: Make your first commit

→ Click README.md, then the pencil icon to edit it

→ Write a 3-line product brief for anything you like. A coffee ordering app, a team lunch planner. Problem, user, goal

→ Click Commit changes

→ Commit message: "Add first product brief"

→ Keep "Commit directly to the main branch" selected and confirm

That's a commit. A saved change, with a note on why.

Because you're working on github.com, there's no separate push. Commit and push happen in one click.

Step 3: Create a branch

→ Click the dropdown above the file list that says main

→ Type update-brief

→ Click "Create branch: update-brief from main"

You're now on your own copy. Main is untouched.

Step 4: Change something on your branch

→ Check the dropdown says update-brief

→ Open README.md and click the pencil

→ Add one line: a success metric. For example, "Success: half the team uses it every week"

→ Commit changes with the message "Add success metric"

Step 5: Open a pull request

→ Go to the Pull requests tab and click New pull request

→ Compare update-brief with main

→ Look at the diff. Green lines were added, red lines were removed. This is exactly what your developers review

→ Click Create pull request, add a title and a one-line description, then click Create pull request again

Tip: GitHub often shows a yellow "Compare & pull request" banner right after you commit to a new branch. It takes you to the same place.

Step 6: Review your own PR

→ Open the Files changed tab

→ Hover over your new line, click the blue +, and leave a comment. For example: "Is half the team realistic?"

That's a code review. Someone reads the change line by line and asks questions before it goes in.

Step 7: Merge

→ Go back to the Conversation tab

→ Click Merge pull request, then Confirm merge

→ Click Delete branch. The work is in main now, the branch did its job

→ Open the Code tab. Your success metric is on main

That's it.

You just ran the same workflow your developers use every day. YOU DIT IT!

​
​
​

What do you think?

Did you try the exercise?

Hit reply and tell me how far you got. Or send me a screenshot of your first merged PR, I'd love to see it.

See you next week,

Maria