Creating a Pull Request

Creating a pull request is a three-part process: make your changes on a branch, push the branch to GitHub, then open the PR through GitHub’s interface.

Step 1 — Create and push a feature branch

git switch -c feature/add-difficulty-ratings

Make your changes, stage them, and commit:

git add pine-ridge.txt
git commit -m "Add difficulty rating to Pine Ridge trail notes"

Push the branch to GitHub with upstream tracking:

git push -u origin feature/add-difficulty-ratings

After pushing, GitHub will show a prompt:

remote: Resolve conflicts before your pull request can be merged.
remote:
remote: Create a pull request for 'feature/add-difficulty-ratings' on GitHub by visiting:
remote:      https://github.com/yourusername/git-practice/pull/new/feature/add-difficulty-ratings

You can use that link or navigate to the repository on GitHub — a yellow banner will appear at the top offering to open a PR for the recently pushed branch.

Step 2 — Open the pull request

Click Compare & pull request (or use the link from the push output). GitHub shows a form with:

Base branch: The branch you want to merge into — usually main. Verify this.

Compare branch: The branch with your changes — should already be set to feature/add-difficulty-ratings.

Title: A concise summary of the change. Pre-filled from your last commit message. Edit it to describe the overall purpose of the PR if your last commit message is too narrow.

Description: The most important field.

Writing a good PR description

A good description saves reviewers time and creates a useful record:

## What this changes

Adds difficulty ratings (Easy / Moderate / Hard) to each trail note
in pine-ridge.txt. Previously we only had distance and time estimates.

## Why

Users asked for difficulty context after the trail got popular with
beginners who found the route harder than expected.

## How to test

1. Open pine-ridge.txt
2. Confirm each trail entry now has a "Difficulty:" line
3. Check that formatting is consistent across all entries

The description does not need to be long — it needs to answer: what changed, why, and how would a reviewer verify it?

Avoid descriptions like “Updated file” or “Fixed stuff” — these tell reviewers nothing.

Step 3 — Submit the pull request

Click Create pull request. GitHub opens the PR and notifies any collaborators (or, if it is just you, you are taken to the PR page).

What the PR page shows

Conversation tab: The description and a thread for comments. This is where reviewers leave overall feedback.

Commits tab: Every commit on the branch. If you push more commits later, they appear here automatically.

Files changed tab: A unified diff of every file changed. This is what reviewers read. Line numbers in green are additions; red are deletions.

Checks: If you have CI set up (tests, linters), their status appears here. A green checkmark means the branch passes automated checks.

Adding more commits to an open PR

If you need to make changes after opening the PR (to address review feedback or fix a mistake):

# make changes
git add .
git commit -m "Address review: normalize difficulty label casing"
git push

The new commit appears on the PR automatically. No need to close and reopen.

Exercise

1. In your git-practice repository, create a new branch:

git switch -c feature/trail-difficulty

2. Add a line to pine-ridge.txt:

echo "Difficulty: Moderate" >> pine-ridge.txt
git add pine-ridge.txt
git commit -m "Add difficulty rating to Pine Ridge trail"

3. Push the branch:

git push -u origin feature/trail-difficulty

4. On GitHub, open a pull request from feature/trail-difficulty into main. Write a two-sentence description explaining what the change is and why it is useful.

5. On the Files changed tab, read the diff. Hover over a line — a + icon appears. Click it to add a line-level comment (you can comment on your own PR).

6. Do not merge yet — the next lesson covers reviewing and merging.

Recap

• Create a feature branch, commit your changes, and push with git push -u origin <branch>.
• Open a PR on GitHub from the branch comparison page or the banner that appears after pushing.
• The base branch is the merge target (usually main); the compare branch is your feature branch.
• Write a description that covers what changed, why, and how to verify it — even for solo work.
• Additional commits pushed to the branch appear on the open PR automatically.

Next: reviewing and merging a pull request — reading diffs, leaving comments, and choosing a merge strategy.