💡 A pull request isn’t just a code submission — it’s the entire conversation around a contribution, and understanding it unlocks real open-source collaboration.
The Fork-Clone-Push-PR Cycle (And Why It Confuses Everyone)
Contributing to open source sounds intimidating until you’ve done it once. Then it just becomes a workflow — a repeatable pattern you run almost on autopilot.
The confusion usually comes from mixing up three things that sound similar: forking, cloning, and branching. They happen in a specific order for a reason. Get that order wrong and you’ll end up pushing to the wrong repository, which is exactly as awkward as it sounds.
I went through this the first time I tried contributing to a small open-source project — ended up cloning the original repository instead of my fork, made changes, then couldn’t push because I didn’t have write access. Spent an embarrassing amount of time figuring out what I’d done wrong.
Here’s the workflow, done correctly.
Step 1: Forking a Repository
💡 Forking creates your own copy of someone else’s project on GitHub — it’s the starting point for every external contribution.
When you find a project you want to contribute to, you can’t just push changes directly to it. You don’t have write access. Instead, you fork it — GitHub creates an identical copy of the repository under your account.
Click the “Fork” button in the top-right corner of any GitHub repository page. That’s it. Within seconds, you have your own version at github.com/your-username/project-name.
Your fork is independent. You own it completely. Changes you make there won’t affect the original project — called the “upstream” repository — unless you explicitly request them to via a pull request.
💡 Keep your fork up-to-date with the original project by adding the upstream remote:
git remote add upstream [original-url], then periodically runninggit pull upstream main.
Step 2: Cloning to Your Local Machine
💡 Clone your fork — not the original — to work on it locally. This single distinction prevents a lot of beginner headaches.
Once your fork exists on GitHub, you need a local copy to actually edit files. That’s cloning.
git clone https://github.com/your-username/project-name.gitThis downloads the entire repository — all files, all history — to a new folder on your machine. You’re now connected to your fork as the “origin” remote.
Before making any changes, create a feature branch. Working directly on main is technically possible but considered poor practice:
git checkout -b fix/typo-in-readmeDescriptive branch names matter here. When your pull request gets reviewed, that branch name is one of the first things maintainers see.
flowchart TD
A[Find project on GitHub] --> B[Fork repository\nto your account]
B --> C[Clone YOUR fork\ngit clone fork-url]
C --> D[Create feature branch\ngit checkout -b feature/name]
D --> E[Make changes\nEdit files locally]
E --> F[Stage and commit\ngit add + git commit]
F --> G[Push to your fork\ngit push origin branch-name]
G --> H[Open Pull Request\non GitHub]
H --> I{Review}
I -->|Changes requested| E
I -->|Approved| J[Merged! 🎉]
Step 3: Making Changes and Pushing to Your Fork
Make your changes. Run your tests. Check everything works. Then:
git add .
git commit -m "Fix typo in README installation section"
git push origin fix/typo-in-readmeThe git push origin branch-name part is important — you’re pushing to your fork (origin), not the original project.
Here’s what a realistic example looks like. A developer I know — mid-20s, building their first open-source contributions portfolio — spotted a bug in a popular CSS framework’s documentation. The code examples in one section were outdated. They forked the repo, cloned it locally, created a branch called fix/update-flexbox-examples, updated three files, committed with a clear message, pushed to their fork, and opened a PR. The maintainer merged it within 48 hours. That contribution now sits on their GitHub profile permanently.
Small contributions like that are often the best starting point. Maintainers love documentation fixes and bug reports with reproducible examples.
Step 4: Submitting a Pull Request
💡 A great pull request description does half the reviewer’s job for them — don’t skip it.
After pushing your branch, GitHub will show a banner at the top of your repository suggesting you open a pull request. Click “Compare & pull request.”
You’ll see a form asking for a title and description. Fill both out properly. The title should be a clear one-liner: what changed and why. The description should explain:
- What problem this solves
- What you changed and why you chose that approach
- How to test it (if applicable)
- Any related issues (link them with “Fixes #123”)
After submission, maintainers will review your code. They might approve it, request changes, or ask questions. Respond promptly and professionally — this is a conversation, not a transaction.
Plot twist: getting a PR rejected or heavily reviewed early on is actually a good thing. The feedback teaches you the project’s standards faster than any documentation would. I’ve learned more from a single detailed code review than from hours of reading tutorials.
💡 If a maintainer requests changes, push new commits to the same branch — the pull request updates automatically without you needing to close and reopen it.
sequenceDiagram
participant You
participant YourFork
participant OriginalRepo
participant Maintainer
You->>YourFork: git push origin feature/fix
You->>OriginalRepo: Open Pull Request
Maintainer->>OriginalRepo: Review code
Maintainer-->>You: Request changes
You->>YourFork: Push updated commits
Maintainer->>OriginalRepo: Approve + Merge
OriginalRepo-->>You: Contribution merged!
The whole fork-clone-push-PR cycle sounds like a lot of steps. The first time, it genuinely takes some focus. By the fifth time, you’ll run through it in under ten minutes without thinking.
Open source is built entirely on this workflow. Every library you’ve used, every framework you’ve depended on — the contributions that shaped them came through pull requests exactly like the one you’re about to open.
Related Articles
- Getting Started with Git: Installation and Setup
- Essential Git Commands Every Developer Should Know
- Git Workflow for Real-World Projects
Back to Complete Guide: GitHub Tutorial for Beginners: Complete Git and GitHub Guide
Leave a Reply