Opening a Pull Request

Everything so far has been local. A pull request (PR) is where Git work becomes visible and reviewable by other people — the actual point of using it on a team.

Push your branch

A branch only exists on your machine until you push it:

git push -u origin feature-x

The -u (short for --set-upstream) links your local branch to the remote one, so future git push/git pull on this branch don't need the full origin feature-x again.

Opening the PR

On GitHub (or GitLab/Bitbucket — the concept is the same, "merge request" on GitLab), pushing a branch usually surfaces a prompt to open a pull request against main. A PR is really two things bundled together: a diff (what changed) and a conversation (comments, requested changes, approvals) attached to that diff.

A PR description worth writing answers three questions a reviewer always has: what changed, why, and how to verify it (steps to test, or what output/behavior to expect). "Fixed the bug" is not a PR description a reviewer can act on quickly.

What a reviewer is actually checking

Not just "does this work" — also: is this the smallest reasonable change for the problem, is anything surprising left unexplained, and would they understand this diff coming back to it in six months with no memory of this conversation. That's the same bar your own commit messages were aiming for, back in lesson two — a PR is that same discipline applied at a larger scale.

This track's completion step

Once you've completed every lesson in this track, come back to the Git & GitHub track page and paste the URL of a real pull request you opened — on this practice repo, on a real project, on an open-source repo, doesn't matter which. That's your evidence: a real PR, not a screenshot, with a permanent link you can put on a résumé.