Tech for PMs — what are commits, branches and pull requests?

Published in

Geek Culture

7 min readAug 3, 2021

If you’ve ever been within earshot of software developers, you’ve probably heard some of the following terms: push, pull, pull request (PR), peer review (also PR), code review, commit, merge, revert, repo, branch, master, feature, Git, GitHub, GitHub Actions, Gitlab…

Early on in my product career, I figured these were coding terms that devs needed to know and that I could get by as long as there was a nice feature to release to customers at the end.

But, with time, I came to understand that knowing the basics of what developers did allowed me to empathise when problems arose, help the team to make trade-offs and manage expectations of stakeholders.

Here’s the article I wish I’d read when I started…

TL;DR

GitHub is a code repository. When developers build an app, they use GitHub to host the app’s code & make changes to it. Sort of like Google Slides for a shared presentation.

In GitHub, the final code that customers see is kept on the master branch. A developer doesn’t code directly into the master branch. Rather, they code on their computer before pushing the code to GitHub, usually to a feature branch.

Code has to be reviewed by another developer before the feature branch is merged into the master branch. This is called a “pull request” and ensures code entering the master branch meets the team’s standards.

It’s useful for a PM to know how developers use GitHub in order to be able to empathise when problems arise.

The analogy

Imagine that you and 10 product manager colleagues need to create a long slide presentation (think more than 200 slides) for the executive team of your company, laying out the progress the product teams have made over the past quarter & presenting plans for the following quarter.

A great tool to produce this deck would be Google Slides because it allows you to:

Work simultaneously with your colleagues, seeing how your changes and their changes look in real time
Save your changes easily and regularly
Revert back to any previous version of the deck

A bunch of PMs building a slide deck is not that different to developers coding an app.

In its simplest terms, GitHub is Google Slides for devs. It is a common space (a code “repository” or “repo”) for a team of developers to collaborate on the app they’re working on.

Preparing your slides — cloning

Working on an important slide deck, it’s unlikely that you would begin by creating slides directly in the final presentation document. Only the clean, high-quality version of your slides make it there. The first step, before starting to create slides, is to sketch out a rough structure & storyline for your slides on a notepad.

Likewise, as a developer, you wouldn’t just start coding in the main codebase right away. Instead, you’d duplicate (“clone”) the code you find in your team’s GitHub repo and download it to your own computer (your “local machine”). Your computer is now a sort of sandbox (or notepad) where you can work on your changes with the knowledge that you’re not messing up the rest of the codebase.

Your first draft — commits & version control

Now the code is on your computer. Every time you write a few lines of code and you’re happy with them, you can save what you’ve done. This is known as a “commit” or “committing your code”.

The cool thing about a commit is that, instead of writing over your existing version, it saves your work as a completely new version. Kind of like a “save as” rather than a standard “save”. So if you ever mess up and need to go back to a previous version, you can just look for the commit that you want to return to. This is called “reverting”.

This is a major value-add for developers. If they find out some code they wrote was not compatible with the rest of the codebase (a “breaking change”), they can simply revert back to a previous commit.

It’s similar to the “version history” feature in Google Slides (see below).

OK, so now you’ve started coding your feature on your computer, making some commits as you go. Once you’ve coded a meaningful part of your feature, you’ll want to try and move that code from your computer to the GitHub repo to see how it works with the rest of the app’s code.

Quality control — branches and pull requests

Back to our slide analogy for a minute. Let’s say your sub-team of PMs (3 of you) is responsible for presenting your scope of the product.

Between you, you might decide to set up a temporary slide deck so that everyone in the sub-team can add their slides without the other sub-teams seeing your work in progress. You’ll only move the slides into the main presentation once you’re happy they’re of sufficient quality.

This is how “branching” works. The main codebase (that customers see) lives in the trunk of the tree 🌳, also known as the “master branch”. Only quality-controlled code makes it into the master branch, otherwise the app could break.

So before starting, the sub-team working on a particular feature clones the master branch, creating a “feature branch”, so they can work on the feature without affecting the main codebase.

So, as a developer working on a feature on your computer, once you’ve coded a meaningful part of the feature, you would “push” it from your computer to the feature branch. Once it’s there, you can see how well it works with the rest of your sub-team’s changes.

Once you and your sub-team are happy with how the feature works on the feature branch, the next step is to get your code onto the master branch. But not so fast…

—

If you’re presenting something to the Exec team of your company, it’s not just your reputation on the line but everyone in the team’s. So you can imagine that in order to make it into the final presentation, all slides are going to be rigorously checked for quality. The consequences of a poor quality slide could be disastrous.

In order to move your code from the feature branch to the master branch, it needs to be checked for quality by one of your colleagues. For this, you need to open a “pull request” or “PR”. This is you requesting that a teammate checks your code meets the standards that you’ve set within the team & if it does, pulling (or “merging”) the feature branch into the master branch.

Your colleague may have some feedback for your code, so you’d need to action that first before they give your PR the green light. This step is crucial to maintaining a good quality codebase & reducing the chance of bugs in the app.

This is also when you would run integration tests. You might remember these from the last post on CI/CD.

Bringing everything together — merging

Since the PM sub-teams have been working on their part of the deck independently of each other, when the slides come together in the final presentation, there may be some tweaks required to make it all fit together & make sure the storyline flows.

Likewise, since sub-teams have been working independently on their feature branches, when they try and merge these into their master branch, it doesn’t always go smoothly. Teams experience “merge conflicts” where branches don’t play nicely together — these can be a real pain to sort out, sometimes taking days and delaying releases to customers

Sharing the final version — release branch

Once you’ve solved any merge conflicts and you’re confident your master branch is in good shape, it’s time to release your new feature(s) to customers.

Some teams create a separate branch for this, called a “release branch”. Think of a release branch as a new version of the app that customers will be able to download from the app store.

To sum it all up…

…the process looks a little like this.

Get access to the GitHub repository
Clone the codebase and download it to your computer
Write your code, committing it every few lines
Push your code from your computer to the feature branch
Ask a teammate for a pull request, react to their feedback
Merge the feature branch into the master branch, solve any merge conflicts
Create a release branch and release the new version of your app to customers

How does this impact you as a PM?

The ins and outs of GitHub, branches and version control are not pivotal in your day to day role as a PM. But having this knowledge can help foster a constructive relationship with the developers in your team.

Example: some complex merge conflicts have arisen as the team is about to release an eagerly awaited feature.

Knowing that a merge conflict can be complex and highly time-consuming to unravel, you empathise with the developers working on it. You show patience & understanding, deprioritise regular sprint work to create capacity & manage expectations with internal stakeholders regarding the upcoming release. Longer term, you facilitate a retrospective with your team to work towards an optimal branching strategy.

Also, (if you have a bit of time on your hands) logging into GitHub and keeping an eye on pull requests can also be beneficial. Front end developers often attach screenshots or GIFs of what they’ve coded in that PR. If you spot something’s not quite right, you could leave them some feedback. Or simply note how much progress they’ve made on the feature they’re building.