Pull Requests: The Core GitHub Workflow

Build the mental model

A pull request, almost always shortened to PR, is a request to review and merge a branch's changes into another branch — typically your feature branch into main. It is GitHub's central workflow, the mechanism through which nearly all collaborative changes to a shared repository happen.

The steps build directly on what you already know from local Git: create a branch, change code, commit as usual.

Push the branch

What's new is what happens after: you push that branch to GitHub with git push -u origin <branch-name>.

Open the pull request

Open a pull request on GitHub's website, pointing from your branch to the branch you want to merge into.

Review

Opening a PR does not merge anything by itself — it starts a conversation. Reviewers can leave comments, request specific changes, run automated checks through Actions.

Merge

Once everyone is satisfied, someone clicks merge, which is the GitHub-hosted equivalent of git merge, performed on the server.

A good pull request title states what changed in one specific sentence — 'Add input validation to login form,' not 'fix stuff.' The description explains why the change exists, what it does not cover, and links any related issue.

Keep PRs small

Small, focused pull requests get reviewed faster and merged with fewer problems than large ones bundling unrelated changes together. Treat the PR description as documentation for your reviewer and your future self: assume nobody remembers the context you have right now, and write accordingly.

text

THE PULL REQUEST FLOW
---------------------
branch --> commit --> push --> open PR --> review --> merge
  |          |          |         |           |          |
 git        git        git      GitHub     comments/   git merge
checkout    commit    push -u   (web UI)    approve     (server)
  -b

Connect it to a real scenario

The local half of opening a pull request is exactly what the code below runs for real: create a branch off main, edit a file, commit with a normal message, then push it with -u so Git remembers to track that branch against origin from now on.

The push output confirms a new branch now exists on the remote — that alone does not create a pull request.

What happens on GitHub

When you push a branch to an actual GitHub-hosted remote, GitHub notices the new branch and shows a 'Compare and pull request' banner on the repository page, offering to prefill a PR from that branch automatically.

Clicking it opens a form with the title and description fields discussed above. From there, reviewers get notified, comments and requested changes appear inline on the diff, and once everything is approved, a merge button becomes available.

None of that web-side interaction has a terminal command — it is worth running the push yourself so the local half feels concrete, then imagining the GitHub page picking up exactly where the terminal output leaves off.

A pull request is a request to review and merge a branch's changes
Only after pushing with -u can you open a PR on GitHub — pushing alone never auto-creates one
A specific title plus a description that explains why gets reviewed faster — keep PRs small and focused

Before Opening a Pull Request

The title describes exactly what changed, in one specific sentence
The description explains what changed and why
Any related issue is linked (e.g. "Closes #12")
Tests pass locally before pushing
No unrelated changes are mixed into the branch
You've reviewed your own diff once before asking anyone else to

Try the working example

bash

# A local bare repo stands in for the GitHub-hosted remote, so branching,
# committing, and pushing below are all genuinely real -- only opening the
# actual Pull Request afterward happens on GitHub's website.
git init -q --bare ../remote-demo.git
git init -q -b main
git config user.name "Thuta Learner"
git config user.email "learner@example.com"
git remote add origin ../remote-demo.git

echo "// app entry point" > app.js
git add app.js
GIT_AUTHOR_DATE="2026-01-01T09:00:00" GIT_COMMITTER_DATE="2026-01-01T09:00:00" \
  git commit -m "Initial commit"
git push -u origin main

git checkout -b feature/add-login
echo "function login() { return true; }" > login.js
git add login.js
GIT_AUTHOR_DATE="2026-01-01T10:00:00" GIT_COMMITTER_DATE="2026-01-01T10:00:00" \
  git commit -m "Add basic login function"
git push -u origin feature/add-login

You should see

git push -u origin main ->
To <remote-url>
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.

git checkout -b feature/add-login, then commit, then:

git push -u origin feature/add-login ->
To <remote-url>
 * [new branch]      feature/add-login -> feature/add-login
branch 'feature/add-login' set up to track 'origin/feature/add-login'.

On an actual GitHub-hosted remote, pushing a new branch also makes GitHub show a "Compare & pull request" banner on the repository page — that part only appears on GitHub's website, not in this terminal output.

5-minute try-it

Create a new branch off main, change a file, and commit it. Then run git push -u origin <your-branch>. Find the phrase "new branch" in the push output — that is the first signal that a PR could now be opened on GitHub.

One important caution

Assuming pushing a branch automatically creates a pull request — you still need to explicitly open one on GitHub's website after pushing

Writing a vague PR title like 'fix' or 'update' instead of something specific — it strips context a reviewer needs

GitHub Docs: About pull requests — Git & GitHub