Git Pull Requests

What a Pull Request Actually Is

It's worth being precise here: a pull request, often shortened to PR, is not a Git feature at all. It's a feature provided by hosting platforms like GitHub, GitLab, and Bitbucket, layered on top of ordinary Git branches and commits. When you open a PR, you are asking the platform to compare two branches (or a fork branch against the original repository) and present that comparison as a reviewable, discussable unit of work before it gets merged.

Under the hood, a pull request is really just a diff between a source branch and a target branch, paired with a comment thread, a review workflow, and often automated checks like tests or linters. The actual merge, when it eventually happens, is performed using ordinary Git operations, most commonly a merge commit, a squash merge, or a rebase, depending on the project's conventions.

Forks vs Branches

There are two common shapes a pull request workflow can take, and which one applies depends on whether you have write access to the original repository. If you're a core contributor with push access, you typically create a new branch directly on the shared repository, push it, and open a PR from that branch into main. If you don't have write access, for example when contributing to an open-source project you don't maintain, you first fork the repository, creating your own copy under your account, make your branch and commits there, and then open a PR from your fork back into the original project.

• Branch workflow: create a branch on the shared repo, push it, open a PR into main
• Fork workflow: fork the repo to your account, branch and commit there, open a PR from your fork into the upstream repo
• Both workflows produce the same kind of PR from the reviewer's perspective, just with a different source location

A Typical Branch-Based PR Flow

$ git checkout -b fix/login-timeout
Switched to a new branch 'fix/login-timeout'

$ git add src/auth/session.js
$ git commit -m "Increase login session timeout to 30 minutes"

$ git push -u origin fix/login-timeout
...
remote: Create a pull request for 'fix/login-timeout' on GitHub by visiting:
remote:      https://github.com/acme/project/pull/new/fix/login-timeout
To github.com:acme/project.git
 * [new branch]      fix/login-timeout -> fix/login-timeout

Notice that git push itself has no concept of pull requests; it simply uploads the branch. GitHub, watching for new branches, prints a helpful shortcut URL in the terminal output that takes you straight to the 'open a pull request' form on the website.

The Review Cycle

Once a PR is open, reviewers can leave comments on specific lines, request changes, approve, or in some setups block a merge until CI checks pass. If a reviewer asks for changes, you simply commit more work on the same branch and push again; the existing PR updates automatically to show the new commits, there is no need to open a new PR for follow-up fixes.

$ git add src/auth/session.js
$ git commit -m "Address review: extract timeout constant"
$ git push
Enumerating objects: 5, done.
...
To github.com:acme/project.git
   9a01cde..1120fab  fix/login-timeout -> fix/login-timeout

Merge Strategies

Good PR Hygiene

Small, focused pull requests get reviewed faster and more carefully than sprawling ones. A PR that changes one thing with a clear description is far easier for a reviewer to reason about than a five-thousand-line diff touching a dozen unrelated files. Writing a clear PR description, referencing any related issue, and keeping commits logically organized all make the review process smoother for everyone involved.