Session 15: Pull Requests: Your project's front door

You built a feature on a branch. Good commit messages, tidy work. Now you want to get your code into master.

You could do git merge and be done. But in a team that doesn’t work. Someone else has to look at your code first: check for mistakes, for style, for things you missed. That is a pull request.

A pull request (PR) is a request: “Bring my changes in.” You open it on GitHub. Your teammates look at your code and give feedback. You change things. Only when everyone is happy does the code go to master.

In this session you make your first pull request. You review a buddy’s. And you find out what real teamwork with Git feels like.

What you’ll learn today

  • What a pull request is and why teams use it
  • Opening a PR on GitHub
  • Updating your PR after feedback
  • Reviewing someone else’s PR
  • Merging a PR and cleaning up the branch

Step 0: Preparation: working in pairs

Today you work together with a buddy. Agree who is the author (who builds the feature) and who is the reviewer (who looks at the PR). Halfway through you swap.

The author needs a GitHub repo that the reviewer has access to. The easiest way:

  1. The author creates a repo on GitHub (public).
  2. The author goes to Settings → Collaborators → Add people.
  3. The author invites the reviewer with their GitHub username.
  4. The reviewer accepts the invitation (via email or GitHub notifications).

Now you can both push to the same repo.

Alternative (without collaborator access): the reviewer forks the author’s repo and opens a PR from the fork to the original. But today we keep it simple: direct collaborator access.

Step 1: Creating and pushing a feature branch (author)

The author clones the repo (if that hasn’t happened yet) and creates a feature branch:

git clone https://github.com/AUTEUR_USERNAME/ons-samenwerk-project.git
cd ons-samenwerk-project
git switch -c feature/groet-functie

Create a new file:

echo 'def groet(naam):' > groet.py
echo '    return f"Hallo {naam}!"' >> groet.py

Commit and push:

git add groet.py
git commit -m "Add groet function

Returns a greeting for the given name."
git push -u origin feature/groet-functie

Step 2: Opening a pull request (author)

  1. Go to your repo on GitHub.
  2. GitHub now shows a yellow bar: “feature/groet-functie had recent pushes”: click Compare & pull request. (If you don’t see the bar: click the Pull requests tab, then New pull request, choose base: master ← compare: feature/groet-functie.)
  3. Write a clear title: “Add groet function”
  4. Write a description. A good PR description has three parts:
## What

A function `groet(naam)` that returns a greeting.

## Why

We need a reusable greeting for the user interface.
This stops us having to write the same string in
several places.

## How to test

```python
from groet import groet
print(groet("CoderDojo"))  # "Hallo CoderDojo!"
5. Click **Create pull request**.

Your PR is now open. Everyone with access to the repo can see it. GitHub shows the diff: exactly which lines you added (green) and removed (red).

## Step 3: Reviewing a PR (reviewer)

The reviewer opens the PR on GitHub. These are the steps of a review:

### 1. Read the description

Do you understand what this PR does? If not, ask for clarification.

### 2. Look at the diff

Click the **Files changed** tab. GitHub shows every changed line. Look at:

- **Does the code work?** Would you run it yourself if you cloned it?
- **Is the style consistent?** The same naming conventions as the rest of the project?
- **Are there mistakes?** Typos, missing imports, logic errors?
- **Are there no secrets in it?** Passwords, API keys, tokens?
- **Is it understandable?** Can someone seeing this code for the first time follow what happens?

### 3. Give feedback

Click a line to add a comment. Be specific:

**Good feedback:**
> In `groet.py` line 2: what happens if `naam` is empty? Maybe add a default value?

**Bad feedback:**
> This isn't good.

### 4. Submit your review

Click **Review changes**. You have three options:

- **Comment**: just feedback, no decision.
- **Approve**: the code is good, it can be merged.
- **Request changes**: something has to change before the PR can be merged.

On your first review: choose **Approve** if everything looks good, or **Request changes** if you want something changed.

## Step 4: Handling feedback (author)

The reviewer left a comment. The author changes the code:

```bash
# Make sure you're on your feature branch
git switch feature/groet-functie

Change groet.py based on the feedback. For example:

def groet(naam="wereld"):
    return f"Hallo {naam}!"

Commit and push:

git add groet.py
git commit -m "Add default parameter to groet function"
git push

The new commit automatically appears in the PR. The reviewer sees the update and can look again.

Step 5: Merging and cleaning up

If the reviewer has Approved, it’s time to merge.

On GitHub, in the PR, you click Merge pull request. Choose Create a merge commit (the default option). Click Confirm merge.

The feature branch is now merged into master. On GitHub you can delete the branch with the Delete branch button that appears after merging.

Locally you have to clean up too:

git switch master
git pull                      # fetch the merge that just happened on GitHub
git branch -d feature/groet-functie   # delete the local branch

Your master is now up to date. Your feature branch is gone, locally and on GitHub. Ready for the next piece of work.

The full PR workflow at a glance

1. git switch -c feature/iets        ← Create a feature branch
2. Work, commit, work, commit
3. git push -u origin feature/iets   ← Push to GitHub
4. Open a PR on GitHub             ← Ask for a review
5. Reviewer looks, gives feedback
6. Change code, commit, push        ← Handle feedback
7. Reviewer approved
8. Merge the PR on GitHub             ← Code to master
9. git switch master && git pull       ← Bring master up to date locally
10. git branch -d feature/iets       ← Clean up the branch

Reviewing someone else’s PR: how do you do that well?

A review is not: “Looks good.” A good review is specific, constructive and respectful.

Questions you ask yourself during a review:

  • Do I understand what this code does? (If not: ask for better comments or a clearer description.)
  • Does the code do what the PR description promises?
  • Can this be simpler?
  • Is anything missing? (Error handling, edge cases, documentation)
  • Are there secrets, passwords or personal data in it?
  • Does the code follow the style of the rest of the project?

How to give feedback:

Start with what’s good. Then be specific about what could be better. End with a clear conclusion.

Example:

The function works exactly as described. Two suggestions:

  1. On line 2: a default value for naam would be handy.
  2. Consider adding a docstring that explains what the function returns.

Other than that it looks good. If you change these two things, I’ll gladly approve it.

Showcase

Swap roles with your buddy and do the whole workflow once more: now you are the reviewer.

Show a coach:

  1. An open pull request on GitHub with a description.
  2. At least one review comment on a buddy’s PR.
  3. A successfully merged PR: the feature code is now on master.

See you next time!

This was the last Git session. What you can do now:

  • Version-control your code with Git (init, add, commit, log, diff)
  • Experiment on branches without breaking master (branch, switch, merge)
  • Share your code online via GitHub (push, pull, clone)
  • Write professional commit messages
  • Work together via pull requests: opening and reviewing

This is not “extra”. This is how developers work every day. Whether you make games, build websites, or train AI: Git and GitHub are the tools that keep your project manageable. Use them.

Take it home

  1. Easy: Open a pull request for a change in one of your own projects.
  2. Medium: Ask a friend or family member to make a GitHub account. Invite them as a collaborator and let them review a PR.
  3. Hard: Contribute to a real open source project. Search GitHub for issues with the good first issue label. Fork the repo, make a fix, and open a PR.
  4. Very hard: Build a small project with two others. Use branches, pull requests and reviews. Work as if you’re in a professional team.