GitHub Explained for Product Managers
Pull requests, merges, branching and all that jazz
Look down at your keyboard. You’ll notice that the letters g, i and t are quite close together. You’ll also notice that the letters g,i and t spell the word ‘git’.
In the UK, ‘git’ is a derogatory word, often used to describe a ‘stupid, despicable person’. It’s a word that Roald Dahl might use to describe that chef who bakes Bruce Bogtrotter’s cake in Matilda; not quite someone as monstrous as Mrs. Trunchbull but hideous nonetheless.
Git is also a command line tool, used by developers, to push, pull and modify code in a location known as a repository. More on that later.
If you’re a product manager, unless you’re from a computer science / technical background (many are, many are not), you might be confused about some of the terminology that gets used by your engineers on a daily basis, particularly when it comes to GitHub.
Your first introduction to GitHub might come from an interaction that looks a little like this:
A pull request is created by an engineer and sent around the group for review. If you’re not familiar with github and how it works, you sit silently, ignoring the pull request and hope it will make sense one day. But not today. So long as the work gets done, who cares about things like GitHub, right?
What exactly is GitHub?
‘Facebook for geeks. Instead of uploading videos of your cat, you upload software.” – Wired Magazine
There are two important parts of this definition:
- Upload software
Firstly, GitHub acts like a social network in many respects, and secondly it allows users to upload software. It’s primary function is to allow developers to upload and maintain software but let’s examine the social aspect briefly.
GitHub as a social network
Millions of engineers around the world are on GitHub. GitHub is a social place; engineers communicate with each other, work together on open source projects and add value to the network by producing more content (in this case code). There are endless open source projects on GitHub which engineers will be actively involved in. You want to work on a browser based version of Tetris? Go for it.
Engineers are encouraged to help each other out in the community and it’s all for free (unless you’re working on business related projects in which case you pay for a premium account). The ambition of GitHub is to create an open, collaborative environment where the world’s repositories (buckets of code) live, breathe and evolve over time.
Here’s some of the social functions of GitHub:
- A CV – engineers are encouraged to include links to their GitHub profiles on their CVs / LinkedIn accounts to demonstrate some of the projects they’ve worked on.
- A blogging platform – some engineers use GitHub as a place to write blog posts. For example, this is a post written by an engineer at a unicorn entitled What I wish I’d known about Equity before joining a unicorn.
- A discussion forum – commenting on how to debug politics or the latest javascript framework on GitHub is a fun way to spend time for many people.
GitHub for uploading software
The main function of GitHub is storing repositories of code. If your organisation uses GitHub, your product’s code will be stored on GitHub.
What’s a repository?
You probably know this already but if you don’t, think of a repository as a bucket where your product’s code is stored. It’s also sometimes referred to as a repo.
The repository that is stored on GitHub.com is known as a remote repository. The repository that’s stored on an engineer’s machine is known as the local repository.
How GitHub fits into the overall software development workflow
GitHub is where the code is stored during your sprints and before a deployment happens. Your engineers will be interacting with GitHub several times throughout the week or day as they work on building your product.
Let’s say you have a new engineer on the team. Here’s an example of how they would get started using GitHub and how it fits into the overall software development workflow.
- Clone the repository – make a copy of the remote repository on their local machine so that they can start building feature
- Work on a new story – the engineer writes code to build a new feature
- Commit the changes – the engineer says ‘I’m happy with these changes’, so I’d like to commit them
- Review the changes – a different engineer reviews the code changes, often with a pair
- Merge the changes – the changes get merged into the master branch (more on this later)
- Deploy the release – once everyone’s happy, the work will eventually get released to your users
The benefits of using git and GitHub
One benefit of using GitHub is that it decentralises the codebase. Each developer has a copy of the codebase on their local machine and works on a local copy – or clone – of the codebase. When the work is complete, the work is merged back into the remote copy of the codebase that is hosted on GitHub.
The main benefit of using Git and GitHub is that they facilitate easily manageable version controlling. If something goes wrong with your product, the code changes can be easily reverted back to a previous version. That’s version control. Git and GitHub also allows your engineers to work on different branches of code and then create pull requests to merge the code back together again.
Notice how I said ‘git and GitHub’. Yes, they are 2 separate things.
The difference between git and GitHub
Git is a command line tool which allows developers to create branches of code and manage versions of their code. The command line is that terrifying tool that engineers use to do things you wish you could.
GitHub is the website or service that hosts the repository and helps manage version control through a useful interface. You don’t have to use GitHub to store repositories and there are plenty of alternatives to GitHub available, such as BitBucket.
Git was chosen as a word because it’s easy to type into a keyboard. Your engineering teams will be typing the word git into their command line tool a few times a day.
Each different command performs a different function. For example, when an engineer is finished with a piece of work, they may type:
git commit -a -m “header button changed”
If you’re wondering WTF does that mean? That’s great.
Let’s take a look at some of the most important – and confusing – terms you that are useful to know as a product manager or indeed as a non-technical business person who is interested in learning more.
The most important terms to know as a product manager
- Branches / branching
- Clone
- Commit
- Push
- Pull requests
- Merging
1. Branches / branching
Think of your main codebase a bit like a tree trunk. Now, think of a new feature that was recently launched. This acts like a temporary branch on the tree.
If your team is set up to use feature branches, it’s likely that your team used a branch to build that feature, which is to say that the feature was worked on independently of the main code base – the tree trunk.
When working with git, branches are used to allow developers to work on individual features, without impacting anyone else who may be working on other features.
This allows developers to work in parallel on multiple features and it makes things cleaner from a development perspective. Having a well defined branching strategy can mean it’s easier for your engineering teams to debug problems and help to smooth your release process.
A branching set up might include some variant of the following:
In git, the command for creating a new branch is this:
Terminal command
git branch [branch_name]
2. Clone
Every engineer who works with git and GitHub will have a copy of the repository stored on their local machine. This process is known as cloning. GitHub provides you with a link to the location of your remote repository and this is included in the git command used to clone the repository.
Here’s an example of the link that GitHub provides to describe the location of your repo:
https://GitHub.com/richholmes84/my_first_repository.git
Once the repository is cloned to a local machine, engineers will typically use the terminal tool to navigate to the location of where the project files are stored and they are then free to make changes locally and push the changes back to the remote location once the work is finished.
Terminal command
git clone https://GitHub.com/richholmes84/my_first_repository.git [clone_name]
3. Commit
When a piece of work is complete on the local machine, the engineer will commit it. This means they are happy with the work they’ve done and they’d like to merge it into the main codebase. It’s a signal of confidence to say ‘I believe I’ve done the work required so I’d like to commit it’.
Terminal command
git commit -a -m “Your message"
Notice a few weird things here. Git commit makes sense, but WTF do the -a and -m bits mean?
-a tells git that you’d like to commit all the files changed since the last commit. You may only want to commit specific files and guess what? Git allows you to specify certain files if that’s the case. However, much of the time engineers will be committing all the files that have been changed.
-m tells git you’d like to include a message along with the commit. It’s good practice for engineers to include a message which describes the nature of the changes that have been committed.
4. Push
In order to get the code changes made from the local machine and into the remote repo hosted on GitHub.com the changes need to be pushed back to the remote repo.
If the changes were not pushed back to the remote repo, they would simply exist on the engineer’s local machine, which would not be very helpful.
Terminal command
git push origin feature branch
This pushes your feature branch to origin. Remember that the remote repo is referred to as origin in git.
5. Pull requests
Let’s revisit our example from earlier:
A member of the engineering team has created a PR – or pull request – and sent it around the rest of the team for input. But what exactly is being pulled – or requested?
When a feature or a piece of work is complete, we now know that the engineer will commit the work. But before the feature branch can be merged back into the master branch, a pull request is normally created.
The pull request is usually a request to pull the feature branch back into the master branch. It’s also typically the time where code reviews happen. Engineer A will commit the work, but before it can be merged into the main codebase Engineers B and C need to review it. This is a code review. Other engineers will review the code quality and standards to ensure this new piece of code isn’t going to make everyone’s life hell by introducing shitty code.
Pull requests can include a wide variety of things; anything that your engineering team have been working on:
- Entire stories
- Bug fixes
- Small feature improvements
- Text changes
If the code quality is deemed to meet the standards that have been set in your company, the pull request will be accepted and the code will be merged back into the master branch.
Merged, you say? Yes.
6. Merging
Some code has been committed and the engineer is happy with it. Is that it? No.
Before a commit can be released it needs to be merged . What does that mean? Remember, the feature is being built on a specific branch, which is often, but not always, a feature branch. A branch on the codebase tree which is specifically designed to be used for 1 feature only.
When the feature work is complete, it needs to be merged back into main branch, often known as the master branch.
Terminal command
git merge [branch_name] - merges the branch
If your branching set up in your engineering team is not clearly defined, merging code back into the main branch can lead to what’s known as merge conflicts. Sounds messy. It sometimes can be.
Git is designed to automatically fix any merge conflicts. However, merge conflicts occur when git can’t figure out how to consolidate branches of code back into the main master branch. This can arise for many reasons, but what you need to know is that fixing merge conflicts can be like trying to untangle a pair of earphones which have been stuck in the bottom of your bag for 3 months. It’s horrible work, but it’s got to be done.
If an engineer says they are working on merge conflicts which may impact the upcoming release, remember 2 things:
- Be patient – The work of resolving merge conflicts can be complex and tiresome, which may mean a delay in the release process. It’s critical therefore to be patient and give the team the necessary time.
- Figure out why – Merge conflicts may (or may not) be symptomatic of wider problems with the team’s devops processes. If the merge conflicts are becoming a regular fixture in your sprint process, have a chat with your lead engineer / to understand why it keeps happening and whether there is any devops optimisation that can be factored in to resolve the likelihood of any future problems.
Bringing it all together – an end to end example
Let’s pretend you’re an engineer, and your idiotic product manager wants you to stop playing ping pong and work on something of value to the business. Appalling, I know, but you grit your teeth and begrudgingly agree to do it.
You’ve had sprint planning, you’ve sized the work as a 1 or 2 and so you’re comfortable with starting the work.
You’re required to change the color of a button from red to blue. Hardly taxing, but always good to factor in a buffer when sizing.
What happens next? Here’s a breakdown of what might happen. Note, these steps will be different for your product but should act as a guide:
1. Clone the repo
If you’re a new engineer on the team, you might not have access to the codebase. If you don’t, you’ll need to clone the repo; that is, make a local copy of the repository on your machine which is cloned from the remote copy of the repo.
With a local copy of the repo cloned to my machine, you’re ready to go.
2. Make the coding changes
Since this is a fairly straight forward front end task, you’ll make the necessary changes. Changing button colors involves a few bits of CSS changes. Your CSS specifies the color blue at the moment, but your product manager wants to change it to red.
OK, here’s the change:
.button {
color: blue;
}
That’s your job done. In a few moments, you’ll be done, but you need to sort out a few bits first.
3. Commit the changes
You’ve made the changes in the CSS, tested it in the browser and the color is indeed now blue, as per the spec. So you’ll confidently commit your changes. To do this, you use the git commit command in your terminal to commit your changes.
git commit -a -m “Color changed from red to blue"
To ensure your fellow developers understand the nature of the change, you’ve included a helpful little message in your commit, which neatly summarises the nature of the change.
This has now committed the changes in your local repo.
4. Push the changes
The changes you’ve made are only made on your local machine, which means you need to push them. Using git push, you push your branch back to the origin repo:
git push origin [branch name]
5. Create a pull request
Before anything can be merged, you need to create a pull request – a request to pull your feature branch back into the master branch.
After you’ve pushed your code to the origin, you create a request to pull it back into master. This triggers a code review.
6. Review the code
The code changes you’ve created are reviewed by your fellow engineers to ensure your code meets the standards set by the team.
Since this is only a small change (changing the color of a button), it’s likely that the code review process won’t take too long.
With the code reviewed, you’ll either get a thumbs up or a thumbs down from the team. If there’s something wrong with your code you’ll need to make some changes and push the new changes, if all is good, you’ll be able to merge your code.
7. Merge the PR
You passed the code review. Congrats.
The last step is merging the feature branch back into the master branch. Before you do that, it’s a good idea to make sure your local and remote repos are in sync. To do this, you pull the latest version to your local machine:
git pull origin master
Then you can do your merge using something like this:
Git merge branchname
With the branches merged, the feature branch can be deleted since the code is now merged in the master branch and is no longer needed.
8. Deploy the release
With your code changed and the button updated, you may have additional sets of tests which run. For example, you may use a tool like jenkins which works as a continuous integration server which basically means it alerts the team to anyone who has added something into the code base that it doesn’t like (because it breaks tests or is hideous).
With your build tests passing, the code is ready to be deployed and your button will be changed in the next release.
If you’re lucky enough to have continuous deployments, that could mean a matter of minutes. If you’re not, it’ll be included in your next sprint.
What you need to know as a product manager
Git and GitHub is by no means an essential skill to have as a product manager. You will never need to use it in your day to day role, so having a deep understanding of git beyond what we’ve covered is a nice to have as opposed to a must-have.
From a product management perspective, it’s useful to consider a few things in regards to git and GitHub:
- Branching set up – If you’re not sure what your branching strategy is for your product, spend a bit of time with your team to understand how a feature gets built, from a branching perspective. Does your team use feature branches, master branches, hotfix branches, release branches or something else? Knowing your branching set up can help you to empathise when things go wrong or when there are conflicts with merging.
- Release processes – do you know how a release happens? Git and GitHub are linked to your release processes. If you haven’t done so in the past, sit with your engineering team and watch how a release happens. If a release takes 2 days and 4 engineers, that’s a problem – and you might want to factor in some time to deal with this into your roadmap. If you can get to a state of continuous deployment you’ll be delighted with the improvements in speed you’ll experience.
- Devops – do you have a dedicated devops person in your engineering team? Git and GitHub is part of an overall devops set up and the goal of devops is ultimately to automate developer workflows. Having a team member dedicated to optimising developer workflows will help to ensure issues with merges and bugs on production get dealt with quickly and efficiently.
So that’s it. Hopefully that’s cleared up some of the questions you have around pull requests, merges, branching and all that other nonsense. Now get back to work, you lazy git.
Podcast
Product Stacks Podcast by the Department of Product. A deep dive into the tools, frameworks and processes used by product managers from top companies.
Product launches, news and analysis delivered to your inbox. Weekly.
