Pull Requests and Code Review, Together

Previously, in Part 6, you pushed clinic-notes to GitHub, wrote a friendly README, and planted your first green square.

Pushing your own code to your own repo is a solo sport. Today we learn the team sport — and the single most important ritual in professional software: the pull request.

The shared kitchen rule

Why don't teams just let everyone push straight to main? For the same reason a restaurant kitchen doesn't let every cook dump ingredients straight into the soup that's heading to customers. One person's "quick little change" can spoil dinner for everyone. Instead, you prepare your dish at your own station, then call someone over: "taste this before it goes in." That taste test is the pull request: "I've made changes on a branch — please review them, and if they look good, pull them into main."

The whole loop, in plain words:

1. Branch — you do your work on a branch, exactly as in Part 4.
2. Push the branch — the branch itself goes up to GitHub, not just master.
3. Open a PR — on GitHub, you ask: "may this branch join main?"
4. Conversation — teammates read the changes, ask questions, suggest improvements.
5. Improve — you push more commits to the same branch; the PR updates itself automatically.
6. Merge — someone clicks the green button, and your work joins the main timeline.

Workshop: fork it

Let's do this for real. There's a snag, though, and it teaches us something important: the workshop repo belongs to rahulvyas777, and you can't open pull requests inside a repository you don't have access to — GitHub would quite rightly ask, "and who are you?"

The answer is a fork: your own complete copy of someone else's repository, living under your GitHub account, where you're the boss. Forks power the entire open-source world — you fork a project, improve your copy, then offer the improvement back. Today we'll keep it simpler and practice entirely inside your own fork.

Go to github.com/rahulvyas777/coder000-git-workshop in your browser and click the Fork button at the top right.

Click Create fork, and a few seconds later you're looking at YOUR-USERNAME/coder000-git-workshop. And here's the lovely part: you don't need to push anything. Open the branch dropdown on your fork and you'll find a branch called add-allergy-field already waiting — a single prepared commit, "Add an allergies field to the patient model and card." Someone did some work on a branch; your job today is to be the teammate who reviews it.

Your first pull request

On your fork, click Pull requests → New pull request. Now, slowly — this screen has one trap for forks. GitHub assumes forks want to send changes back to the original project, so the base repository dropdown may point at rahulvyas777/coder000-git-workshop. Click it and switch the base to your own fork. You want the arrow to read: base master ← compare add-allergy-field, both on YOUR-USERNAME's repo.

GitHub instantly shows the diff below. Click Create pull request — the title fills itself in from the commit message — add a friendly line of description ("Adds allergies to the patient model and shows them on the card"), and confirm. Congratulations: that page you're looking at is a real pull request, identical to the ones flowing through every software company on Earth right now.

Touring the PR screen

Three stops on the tour:

• Conversation — the front page: description, comments, and a timeline of everything that happens to this PR.
• Files changed — the heart of review. Every changed line, removals in red, additions in green. This is where reviewers actually read the code.
• Line comments — hover over any line in Files changed and a little + appears. Click it and you can attach a comment to that exact line. Try it now — comment on the new property, even just "Nice, clear name." Yes, you're talking to yourself. That's how everyone practices.

Review it like a kind teammate

Now read the diff properly, as a reviewer. The golden rule of kind code review: ask questions, don't issue verdicts. "Why did we choose X?" lands better than "X is wrong" — and half the time the answer teaches you something. Looking at this change, a good reviewer might wonder:

• Is Allergies the right shape — one text field, or could a list serve better someday?
• What does the card show for a patient with no allergies — is the empty state tidy?
• Would a small test help pin down the behavior we expect?
• Is the wording on the card the way a nurse would say it?

None of these mean the code is bad. Review isn't a search for someone's mistakes — it's two people making the change better together, and sharing what they learned along the way. It's also increasingly three: many teams now have an AI reviewer leave the first pass of comments on every PR, with humans handling judgment calls — we looked at that world in the AI-assisted coding post.

The three merge buttons

Satisfied with your review? Then merge. The green button hides a dropdown with three options, and this table demystifies them once and for all:

Pick Squash and merge to see the popular one in action, confirm, and enjoy the purple "Merged" badge. Your fork's master now has the allergies feature — and the original repo is completely untouched, because everything happened in your copy.

How real teams sleep at night

One last piece completes the picture: branch protection. On a real team, the main branch is configured so that nobody — not even the boss — can push to it directly. Every change must arrive through a pull request, with at least one approving review, and often with automated tests passing too. It sounds strict, but it's the opposite of stressful: it means no single tired person at 2 a.m. can break the soup. The kitchen rule, enforced by the kitchen itself.

You've now seen the full collaboration loop: branch, push, pull request, review, merge. But seasoned developers do one more thing before opening a PR — they tidy the story first, so reviewers read a clean narrative instead of a rough draft. In Part 8, we learn to make history beautiful: rebase, cherry-pick, and stash.