Pull Requests and Code Review

On your own, merging a branch is a command. On a team, it’s a conversation: someone else reads the change, asks questions, catches the bug you didn’t see, and only then does it land on main. GitHub’s pull request is where that conversation happens. Even on a solo portfolio it’s worth using, because in a few lessons you’ll attach automated checks to it, and because employers look at how you work, not only at what you built.

From branch to pull request

You’ve built a filter for the projects page on a branch and pushed it:

git switch -c projects-filter
# …commits…
git push -u origin projects-filter

The push output includes a link: Create a pull request for 'projects-filter' on GitHub by visiting: https://github.com/maya-okafor/portfolio/pull/new/projects-filter. Open it, or click the “Compare & pull request” banner on the repository page. Check the two branch selectors: base is where the work should go (main), compare is your branch.

With the GitHub CLI, gh pr create asks for a title and body in the terminal, and gh pr create --fill uses your commit messages.

If the work isn’t ready but you want early feedback, open it as a draft pull request. It can’t be merged until you mark it ready, and it tells reviewers to look at direction, not detail.

Write a description people can act on

The title says what the change does: “Add tag filter to projects page”. The body answers three questions:

## What
Adds tag buttons above the project grid; clicking one hides cards without that tag.

## Why
The grid has 14 projects now and visitors asked for a way to find the React ones.

## How to check
1. Open projects.html
2. Click "React": only 5 cards remain
3. Click "All": all 14 return

Closes #12

Add a screenshot for anything visual; you can paste images straight into the box. The last line uses a closing keyword: when this pull request merges into the default branch, issue 12 closes automatically and the two link to each other. Fixes and Resolves work too.

The review

A reviewer opens the Files changed tab, which shows the diff between your branch and its base. They can comment on any line, select several lines for a broader comment, or write a suggestion: a proposed replacement you can apply with one click as a commit. When done, they submit a review as Comment, Approve or Request changes.

To respond, you don’t open anything new. Make the changes locally, commit, and push to the same branch:

git commit -am "Rename filter class to project-filter"
git push

The pull request updates, and the reviewer can see only what changed since their last review. Reply to each comment, resolve conversations that are settled, and ask for another look.

Keep pull requests small. Under about 400 changed lines, a reviewer can actually think about every line; a 2,000-line pull request gets skimmed and approved. If a feature is big, split it into a sequence of pull requests that each leave the site working.

Merging: three buttons, three histories

When approved, the merge button offers up to three methods, which repository settings can limit:

• Create a merge commit: all your commits plus a merge commit, like git merge --no-ff.
• Squash and merge: your commits combined into one new commit on main, titled after the pull request.
• Rebase and merge: your commits replayed onto main one by one, with no merge commit.

Squash and merge is a popular default for small pull requests: main gets one clean commit per change, and “fix typo” commits vanish. Merge commits suit larger work where the individual commits tell a useful story. Pick one per repository and stick to it.

After merging, click Delete branch on GitHub, then tidy up locally:

git switch main
git pull
git branch -D projects-filter

Why -D and not -d? After a squash or rebase merge, your branch’s original commits aren’t ancestors of main (GitHub made new ones), so -d thinks the work is unmerged. Once GitHub shows the pull request as merged, -D is safe.

Checking out someone else’s pull request to test it is one command with the CLI: gh pr checkout 14. Next, you’ll use the rest of GitHub’s collaboration tools, issues and projects to plan work, and forks to contribute to repositories you don’t own.