Pull Requests and Code Review Workflow

What Is a Pull Request?

A pull request (PR) is a formal request to merge code from one branch into another. On GitHub, a PR creates a dedicated conversation thread where team members can read your changes, leave comments, and approve or reject the merge. Pull requests are the standard collaboration tool in professional web and software development teams. They protect the main branch from untested or broken code and create a written record of every change.

Why Code Review Matters

Code review catches bugs that automated tests miss, enforces team style standards, and spreads knowledge across the team so that no single developer becomes the only person who understands a feature. Good review also mentors junior developers and produces better software. Most employers expect every developer to both give and receive code reviews as a daily part of the job.

Opening a Pull Request

Before opening a PR, make sure your feature branch is pushed to the remote repository:

```

git push origin your-feature-branch

```

On GitHub, navigate to the repository. GitHub usually shows a banner offering to open a PR for a recently pushed branch. You can also click Pull requests → New pull request, then select your feature branch as the compare branch and the target branch (commonly `main` or `develop`) as the base.

Writing a Good PR Description

A weak PR title like "fixed stuff" wastes reviewers' time. A complete description includes:

• What changed – a plain-English summary of the code changes.
• Why it changed – the problem being solved or the feature being added.
• Testing done – what you ran or manually checked to confirm the code works.
• Links – references to the issue or ticket number if your team uses one.

Many teams provide a PR template (a Markdown file in the repository) that prompts you for each section. Fill every section in; do not delete headings and leave them blank.

Conducting a Peer Code Review

When assigned to review a PR, open the Files changed tab. GitHub shows a line-by-line diff in red (removed) and green (added).

To leave an inline comment, click the blue `+` icon next to any line. Write your comment in the text box. Inline comments are tied to a specific line so the author knows exactly what you mean. At minimum, a professional review includes:

• At least one comment that identifies a concrete improvement (a logic error, a security concern, a naming problem, missing error handling).
• At least one encouraging or neutral observation so the review is balanced.

When you are done reading all the files, click Review changes (top right), write a summary comment, and choose one of three outcomes:

• Approve – the code is ready to merge.
• Request changes – the author must make at least one fix before merging.
• Comment – feedback only, no approval decision.

Submit your review. The author is notified automatically.

Responding to Review Comments

When you receive review comments, read every one before making changes. For each comment you agree with, make the fix in your local branch, commit it, and push again:

```

git add changed-file.js

git commit -m "Address review: rename variable for clarity"

git push origin your-feature-branch

```

The new commit appears in the PR automatically. Reply to the comment on GitHub to let the reviewer know what you did (or explain respectfully if you disagree). The reviewer can then re-examine the file and approve.

Merging the Pull Request

Once a reviewer approves and no required checks are failing, the author merges the PR. GitHub offers three merge strategies:

• Create a merge commit – preserves every commit on the feature branch.
• Squash and merge – combines all commits on the branch into one commit on the base branch, keeping history clean. This is the required option for this lab.
• Rebase and merge – replays commits on top of the base branch.

Click Squash and merge, edit the commit message if needed, then confirm. Delete the remote feature branch afterward to keep the repository tidy.

Professionalism and Safety in Code Review

Code review involves real communication between people. Keep all comments focused on the code, not the person. Phrases like "this function is hard to follow; consider extracting lines 14–20 into a helper" are constructive. Phrases that attack the author's ability are not acceptable and violate most workplace codes of conduct.

From a technical safety standpoint, never merge a PR that introduces credentials (passwords, API keys) into a public repository. If you spot one in a review, flag it immediately with a Request Changes review and notify the instructor. Exposed credentials must be rotated even after deletion because commit history may have been cached.

Recording Your Work

Log the PR number, the merge strategy used, and a one-sentence summary of what was merged in your lab log after every PR activity. This habit mirrors professional practice and gives you a personal record you can reference when building your portfolio.