Pull Requests and Code Review

Updated

October 30, 2026

Pull Requests, Code Review, and Handling Conflicts in Teams

After this page you can describe a pull request as Git operations plus a forge UI.

Git has no pull request object

A pull request (GitHub, Gitea, Forgejo, Bitbucket) or merge request (GitLab) is:

  1. A branch you pushed (feat/ping-json)
  2. A request that another branch (main) integrate it
  3. Discussion, checks, and a button that runs merge, squash merge, or rebase merge on the server

Gerrit uses Change-Ids (chapter 27). SourceHut uses mailing lists (chapter 28). The Git underneath is still fetch + merge or rebase.

 origin/main     A ← B ← C
 origin/feat     A ← B ← C ← D ← E     ← you pushed this

 forge PR        "merge feat into main"
                 = merge, squash, or rebase on the server

Local shape

git switch -c feat/ping-json
# commits
git push -u origin feat/ping-json

On the forge: open a PR from feat/ping-json into main. Reviewers fetch that branch:

git fetch origin feat/ping-json
git log --oneline main..origin/feat/ping-json
git switch -c review-ping origin/feat/ping-json

Conflicts in a PR

The server’s merge is the same three-way merge as chapter 8. Resolve on Linux in your clone:

git fetch origin
git switch feat/ping-json
git rebase origin/main          # or: git merge origin/main
# fix, add, rebase --continue
git push --force-with-lease

The PR updates because the branch name moved.

Review comments

Comments live on the forge. They are not Git objects. Closing a PR without merging leaves the branch on the remote until you delete it. Merging may delete the branch if the forge is set to.

Hands-on next

The next page uses two directories on one Linux machine as “you” and “origin,” so you can push and fetch without an account.