{"id":"l-git-3-3","courseId":"git-github","lang":"en","kind":"lesson","summary":"Open a pull request from a pushed branch, write a description reviewers can act on, review and update code through comments and new commits, and merge with the right method.","html":"

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.

\n

From branch to pull request

\n

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

\n
Terminal
git switch -c projects-filter\n# …commits…\ngit push -u origin projects-filter
\n

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.

\n

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.

\n

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.

\n

Write a description people can act on

\n

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

\n
Markdown
## What\nAdds tag buttons above the project grid; clicking one hides cards without that tag.\n\n## Why\nThe grid has 14 projects now and visitors asked for a way to find the React ones.\n\n## How to check\n1. Open projects.html\n2. Click \"React\": only 5 cards remain\n3. Click \"All\": all 14 return\n\nCloses #12
\n

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.

\n

The review

\n

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.

\n

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

\n
Terminal
git commit -am \"Rename filter class to project-filter\"\ngit push
\n

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.

\n\n

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.

\n

Merging: three buttons, three histories

\n

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

\n\n

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.

\n

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

\n
Terminal
git switch main\ngit pull\ngit branch -D projects-filter
\n

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.

\n\n

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.

\n","toc":[{"id":"sec-1","text":"From branch to pull request","level":2},{"id":"sec-2","text":"Write a description people can act on","level":2},{"id":"sec-3","text":"The review","level":2},{"id":"sec-4","text":"Merging: three buttons, three histories","level":2}],"takeaways":["A pull request proposes merging one branch into another and is the place where discussion, review and automated checks happen.","Pushing more commits to the same branch updates the open pull request; you never need to open a new one.","A good description says what changed, why, and how to check it, and `Closes","Merge commit, squash and merge, and rebase and merge produce different history on main; pick one convention per repository.","After a squash merge, start new work on a fresh branch from the updated main instead of continuing on the old branch."],"further":[{"title":"Pull requests (GitHub Docs)","url":"https://docs.github.com/en/pull-requests/reference/pull-requests"},{"title":"Reviewing proposed changes in a pull request","url":"https://docs.github.com/en/pull-requests/how-tos/review-pull-requests/reviewing-proposed-changes-in-a-pull-request"},{"title":"Pull request merges (GitHub Docs)","url":"https://docs.github.com/en/pull-requests/reference/pull-request-merges"},{"title":"Linking a pull request to an issue","url":"https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue"}],"quiz":[{"q":"

A reviewer asks you to rename a CSS class in your open pull request. How do you update the pull request?

","options":[{"text":"Close it, make the change on a new branch, and open a new pull request.","why":"That throws away the review conversation for no reason. Pull requests are designed to be updated."},{"text":"Commit the change on the same branch and push; the pull request updates automatically.","why":"Correct. A pull request tracks its branch, so new commits appear in it and the reviewer can see exactly what changed since their review."},{"text":"Edit the file in the “Files changed” tab of the pull request.","why":"You can make small edits on GitHub, but it still commits to the branch; it’s not a separate mechanism, and local work is usually easier to test."},{"text":"Ask the reviewer to make the change themselves after merging.","why":"Merging known-unfinished work into main defeats the purpose of review."}],"answer":1},{"q":"

Your pull request description ends with `Closes

","options":[{"text":"Issue 12 is closed automatically and linked to the pull request.","why":"Correct. Keywords like closes, fixes and resolves followed by an issue number link them, and the merge closes the issue."},{"text":"Pull request number 12 is closed.","why":"The number refers to an issue (issues and pull requests share one numbering), and the keyword links rather than closes another pull request."},{"text":"Nothing; it’s only a comment for humans.","why":"GitHub parses these keywords in pull request descriptions and acts on them when merging into the default branch."}],"answer":0},{"q":"

Your team squash-merges pull requests. After yours merged, you kept committing on the same branch and opened a second pull request. It shows your old commits again and conflicts. Why?

","options":[{"text":"GitHub forgot that the first pull request was merged.","why":"GitHub remembers. The problem is in the commit graph, not in GitHub’s records."},{"text":"Squash merging deletes the branch on GitHub, so it’s corrupted.","why":"Deleting a branch after merge removes a pointer. Nothing is corrupted."},{"text":"Your branch needs git pull --force to fix the history.","why":"There’s no such fix, and forcing doesn’t change what’s in main."},{"text":"The squash created one new commit on main, so your branch’s original commits still look unmerged to Git.","why":"Correct. The squash commit has the same changes but a different ID. Start each new piece of work on a fresh branch from the updated main."}],"answer":3},{"q":"

Which pull request is likely to get the most useful review?

","options":[{"text":"One pull request with the whole redesign, 2,400 changed lines, titled “Updates”.","why":"Reviewers can’t hold that much in their heads, so they skim and approve. Size and a vague title both work against review."},{"text":"A pull request with no description, because the code speaks for itself.","why":"Code shows what changed, not why, or how to check it. Reviewers waste time reconstructing your intent."},{"text":"A 150-line pull request adding the projects filter, with a screenshot and steps to test it.","why":"Correct. Small, single-purpose, and explained, so the reviewer can actually check that it works."}],"answer":2}],"exercise":{"kind":"order","items":["branch","push","open","review","update","merge","cleanup"],"title":"Ship the projects filter through a pull request","prompt":"

Put the steps of the pull request workflow in order, from starting the projects filter to having it on main with your local repository tidy.

\n","hints":["A pull request needs a branch that exists on GitHub.","Review feedback is answered by pushing to the same branch, before anything merges.","Local cleanup comes after GitHub has merged and deleted the branch."],"explanation":"

Work starts on a fresh branch from an up-to-date main. Pushing it with -u puts it on GitHub, where you open a pull request against main with a clear description. Reviewers comment; you answer by committing and pushing to the same branch, which updates the pull request. Once approved, it’s merged (here, squashed) and the remote branch deleted. Finally you update your local main and delete the local branch.

\n","checkLabels":{},"itemText":{"branch":"git switch main, git pull, then git switch -c projects-filter.","push":"Commit the work and run git push -u origin projects-filter.","open":"Open a pull request (base: main) with what, why, how to check, and Closes #12.","review":"A reviewer leaves line comments and requests changes.","update":"Commit the fixes on projects-filter and git push; the pull request updates.","merge":"After approval, click Squash and merge, then Delete branch.","cleanup":"Locally: git switch main, git pull, git branch -D projects-filter."}},"words":761,"readMinutes":4}