GitHub Pull Requests

Open a pull request with a clear change set, description, and linked issue so review can start from evidence.

Pull requests are GitHub, not git pull

Git Remote already used git pull: fetch, then integrate a named remote branch into your current branch. A GitHub pull request is different. It is a conversation on GitHub that proposes merging one Git branch into another—usually a feature branch into main. There is no git pr command. Opening the page does not move main until someone merges.

# These are Git. None of them opens a GitHub pull request.
git pull origin main
git fetch origin
git merge origin/main

Git Project: Two Clone Sync pushed commits to main because the job was two working copies sharing history. This lesson is the review path: the default branch stays put until the change is accepted.

Change lives on a branch

Create a short-lived branch from an up-to-date main, as Git Branch taught. One intention per branch. Push that branch. Do not commit the review work on main and then try to open a pull request from main into main—GitHub has nothing to compare.

# From a clone of a GitHub repository YOU own, with a clean main
git switch main
git pull origin main
git switch -c feature/readme-clone-section

# Edit README.md: add a Clone heading and the git clone URL, then:
git add README.md
git diff --cached
git commit -m "Document how to clone this repository"
git push -u origin feature/readme-clone-section
git branch -vv

git push -u origin feature/readme-clone-section sends the commits and sets upstream. After it succeeds, git branch -vv shows [origin/feature/readme-clone-section]. The files on GitHub’s main have not changed yet. That is the point.

Change set, why, verify, linked issue

A useful pull request tells a stranger what to look at. The diff is the change set. The description is the argument.

## Summary
Adds a Clone section to README so a stranger can copy the GitHub Git URL.

## Linked issue
Closes #1

## How to verify
1. Open README.md on this branch.
2. Confirm the clone command uses the GitHub Git URL, not a Pages URL.
3. Confirm no other files changed.

Keep the diff small. A README heading plus one clone command is enough for this lesson. Do not mix a rename, a formatter sweep, and a behavior change in the same pull request—reviewers cannot tell which part is the claim.

Create the pull request

Stay on the feature branch. origin must already have that branch. Then create the GitHub conversation.

gh pr create --base main --title "Document how to clone this repository" --body "$(cat <<'EOF'
## Summary
Adds a Clone section to README so a stranger can copy the GitHub Git URL.

## Linked issue
Closes #1

## How to verify
1. Open README.md on this branch.
2. Confirm the clone command uses the GitHub Git URL, not a Pages URL.
EOF
)"

The website Compare & pull request button is the same object: base main, compare the feature branch, title, body. Fill the body. Do not rely on gh pr create --fill as the quality path; it copies the commit message and skips the verify steps.

Open an issue first if you do not already have one from GitHub Issues. A task issue (“README has no clone command; expected a stranger can copy the Git URL”) is enough. Then put Closes #N in the pull request body with that number.

List, view, and merge on a repo you own

gh pr list
gh pr view 1
gh pr merge 1 --merge

git fetch origin
git switch main
git pull origin main
git log --oneline --decorate -n 5
git branch -vv

gh pr list shows open pull requests on the GitHub repository for this directory. gh pr view 1 prints the description so you can check whether a stranger could review it. On a disposable repository you own, you may self-merge with gh pr merge 1 --merge so GitHub records a merge commit on main. Then fetch and update local main. The merge happened on GitHub; git pull only brings that result home.

Use --merge here so the graph stays a two-parent merge, the shape Git Merge already taught. Squash and rebase merge buttons are GitHub options for a later lesson. Do not force-push the feature branch to rewrite the pull request after you have asked someone to look at it.

Same-repo vs fork pull requests

What not to open

Guided practice: one reviewable PR

1. 01
   Pick a repository you own

   Confirm git remote -v is your GitHub URL. Update local main with git pull origin main.

2. 02
   Open or reuse an issue

   If README has no clone section, that is the problem. Create the issue, or reuse one from GitHub Issues. Record the number.

3. 03
   Branch, commit, push

   git switch -c feature/readme-clone-section. One commit. git push -u origin feature/readme-clone-section.

4. 04
   Create the pull request

   gh pr create --base main with a summary, verify steps, and Closes #N. Then gh pr view.

5. 05
   Merge on GitHub, then pull

   gh pr merge --merge on this disposable repo. Fetch and update local main. Confirm the README change is on main and the issue is closed.

Independent lab: pull request

1. On a GitHub repository you own, open or reuse an issue that names a small, real gap (a missing README section is enough).
2. Create a feature branch, make one focused commit, and git push -u origin that branch. Do not commit the change on main.
3. Open a pull request with gh pr create. The body must include what changed, how to verify, and Closes #N.
4. Show gh pr list including that pull request, and gh pr view of its number.
5. Write five lines: repository URL, branch name, pull request number, issue number, and one sentence that distinguishes git pull from a GitHub pull request. Merge only on this disposable repo. Do not open the pull request on a project you do not maintain.

Common pull request mistakes

Lesson review

You can open a GitHub pull request that a stranger can review, keep git pull distinct from that page, and practice without spamming another project. Line-by-line review comments stay for the next collaboration lesson.

• I know a GitHub pull request is a review conversation, not git pull and not a Git object.
• I can push a feature branch with git push -u origin and leave main unchanged until merge.
• I can gh pr create, gh pr list, and gh pr view with a description that includes verify steps and Closes #N.
• I practice on a repository I own, and I do not open a pull request on a project I do not maintain.