Learn Git - Pull Requests (PR) & Code Review on GitHub

#Introduction

In episode 10 we discussed collaboration workflow patterns: Centralized Workflow, Feature Branch Workflow, Gitflow, and Trunk-Based Development. If you paid attention, almost every modern pattern funnels into the same gateway before code touches main — the Pull Request (PR). A PR is not just a "merge the code" button; it is a space for discussion, quality inspection, and a permanent record of decisions in the repository.

Why does this matter in the real world? Many teams enforce the rule "no code enters main without an approved PR". In large companies, PRs are where code review happens — finding bugs before production, not after. A well-written PR is also a communication bridge: what changed, why it changed, and how to test it. This episode covers how to create PRs, write informative descriptions, perform code review, and choose the right merge strategy.

#What Is a Pull Request?

A Pull Request is a request to merge one branch (source) into another branch (target). It packages everything a reviewer needs in one place:

• Diff — all the code changes being offered.
• Commits — the list of commits that make up the PR.
• Description — the explanation of context, rationale, and how to test.
• Comments & review — feedback from team members.
• Status checks — CI/CD results that must be green before merging.

A PR adds a layer that a plain git merge does not have: human and machine decisions before code is integrated. Git provides the merging mechanism; GitHub provides the mechanism of approval.

#Creating a Pull Request from the GitHub UI

The most common way is through the UI. The flow starts with pushing the branch to the remote:

git switch -c feat/login
git add .
git commit -m "feat: tambah halaman login"
git push -u origin feat/login

After the push, GitHub shows a "Compare & pull request" banner on the repository page. Click that button, then pay attention to three things:

1. Base branch — the target branch (usually main).
2. Compare branch — the source branch (e.g. feat/login).
3. Title & description — filled in according to the template.

Once you are confident, click Create pull request. The PR now has a unique number (e.g. #42) and can be shared with the team.

#Creating a PR with GitHub CLI

CLI practitioners can do everything without opening a browser. Make sure you are logged in with gh auth login (covered in episode 0), then use gh pr create:

gh pr create \
  --base main \
  --head feat/login \
  --title "feat: tambah halaman login" \
  --body "Menambahkan autentikasi pengguna dengan token JWT."

A few gh pr commands you should know by heart:

• gh pr create --fill — fills the title and body automatically from the commits.
• gh pr view — view PR details.
• gh pr checkout — switch to the PR branch to test it directly.
• gh pr merge — merge the PR once it is approved.

gh pr list --state open
gh pr view --web
gh pr merge 42 --squash

#Writing an Informative PR Description

A good description answers the reviewer's questions before they ask. A template common in professional teams:

## Apa yang berubah?
Menambahkan autentikasi login dengan JWT di sisi API.
 
## Mengapa?
Menutup celah autentikasi yang sebelumnya tidak ada.
 
## Screenshot
![Tampilan halaman login](/static/demo/login.png)
 
## Cara menguji
1. Jalankan `bun run dev`
2. Login dengan akun dummy yang sudah dibuat

Screenshots and videos dramatically speed up review. In the browser, you can paste images directly from your clipboard into the description textarea — GitHub uploads them automatically. For visual changes, record a short GIF or video showing the before and after flow.

#The Code Review Process

When a PR is created, reviewers assess the code in the Files changed tab. GitHub provides three forms of feedback:

• Inline comment — a comment attached to a specific line of code.
• Approve — approves the PR, ready to merge.
• Request changes — requests revisions before the code may be merged.

Inline comments are the main tool of code review: you can highlight a specific line, write a question or suggestion, then use the Start a review button to send all comments at once. From the terminal, use gh pr review:

gh pr review 42 --approve
gh pr review 42 --request-changes --body "Tolong tangani kasus token yang sudah kedaluwarsa."
gh pr review 42 --comment --body "Terima kasih, saya tambahkan test besok."

After a reviewer requests changes, the author fixes the code, pushes new commits to the same branch, and the PR updates automatically. The cycle repeats until approval.

#PR Merge Strategies

When the PR is approved, it is time to choose how to merge. GitHub offers three strategies:

Squash and Merge is the default recommendation for most teams. The reasons: history stays tidy — one feature, one commit, easy to read, easy to bisect (episode 17), and easy to revert one feature at a time (episode 14). Small commits like "wip", "fix typo", and "update" made during development do not need to appear on main.

git log --oneline --graph --all -8
git log --oneline --first-parent

The first line shows a graphical history after merging; the second shows only the main commits — with squash, the result is a clean, linear list of feature commits that is easy to follow.

#Closing

This episode takes you from merely pushing code to being a professional collaborator: the Pull Request concept as a quality gateway, creating PRs from the GitHub UI and gh pr create, informative PR descriptions with screenshots, the code review process with inline comments and request changes, and the three merge strategies with a recommendation for Squash and Merge.

The points to take with you:

• A PR packages diff, commits, description, review, and status checks in one place.
• Always check the base branch before creating a PR.
• A good description answers what, why, and how to test.
• Inline comments are the main tool of code review; request changes blocks merging.
• Squash and Merge keeps history tidy and is the recommended default.

A good PR raises the next big question: what should we work on? In episode 12 we cover GitHub Issues, Labels & Milestones — how to record bug reports, feature requests, and tasks, then link them to commits and PRs so issues close automatically. See you in episode 12!