How to review, discuss, and merge changes like a pro without the jargon
This guide is written for solo developers working independently with Git. If you're working in a team or contributing to shared repositories, some practices may differ. We cover team workflows in Part 7.
Pull requests (PRs) are how teams collaborate on code, and how solo devs keep their history clean and structured. If you're using GitHub, learning how PRs work will instantly make you a better contributor.
What Is a Pull Request?
At its core, a pull request is a proposal:
"I made changes in a branch. Here's what I did, why I did it, and I'd like to merge this into the main project."
It creates a safe review zone where others (or just Future You) can:
- See the changes side-by-side (diff view)
- Comment or ask questions
- Approve or suggest edits
- Automatically check for merge issues
When Should You Make a Pull Request?
Any time you're done with a feature, bug fix, or experiment in a branch, make a PR.
Good moments to open one:
- You added a new feature and tested it locally
- You fixed a bug and want someone to double-check
- You're ready to merge changes from your dev branch into main
You don't need to wait until it's perfect. PRs are where feedback happens.
What Happens During a PR?
- You open the PR: Choose a source (your branch) and a destination (usually
mainordev) - Review kicks off: GitHub shows a summary of all changes. You or teammates can leave comments
- Fixes/changes: You can push more commits to the same branch and they'll show up in the PR
- Final review: Everyone agrees it's good to go
- Merge: Hit the button. GitHub takes care of the rest
Solo Devs: Why Bother With PRs?
You might think: "It's just me, why add extra steps?"
Here's why:
- Cleaner history with a clear description of each change
- A safe space to test merge conflicts
- Optional CI/CD checks (like automated tests or linting)
- Easier to revert or reference changes later
You're creating a logbook for Future You.
Common Mistakes to Avoid
- Merging without review: If you're on a team, don't skip the review process
- Forgetting to update your branch: Always pull the latest main/dev before merging
- Using PRs as a backup: They aren't a replacement for commits or pushing often
Best Practices
- Keep pull requests focused, don't mix bug fixes with new features
- Write a clear title and summary for your PR
- Tag reviewers or assign yourself if solo
- Use draft PRs if it's not ready yet, but you want to start feedback early
TL;DR
- PRs let you review, discuss, and safely merge code
- Always branch, edit, PR, review, merge
- They're not just for teams, solo devs benefit too