If you're getting better at programming but still feel unsure about GitHub, learning how to make a pull request is one of the most useful practical skills you can build. It helps you contribute to team projects, understand real developer workflows, and show employers that you can work in a shared codebase, not just code alone.
For many beginners, GitHub feels confusing because the terminology arrives all at once: fork, clone, branch, commit, push, pull request. The good news is that the workflow is not complicated once you understand the order of operations. A pull request is simply the review step at the end of a process: you copy the code to your machine, make changes on a separate branch, push those changes to GitHub, and ask the project maintainers to review them.
This tutorial is aimed at computer science students, first-time contributors, and anyone preparing for internships who wants to build stronger team-development skills. The core workflow here is beginner-friendly and command-line based, which is exactly what makes it valuable: you learn what Git is actually doing instead of just clicking buttons.
All this information and more is covered in the free Industry Projects for Python course, which teaches beginner-friendly, real-world development skills with Git, GitHub, Python, and more: https://industry-python.thinkific.com/products/courses/industry-projects-with-python.
Why pull requests matter
When you work on code by yourself, it's easy to think programming is only about writing files and running programs. In teams, that is only part of the job. You also need to:
- keep your changes isolated
- explain what you changed
- submit work for review
- respond to feedback
- avoid breaking the main branch
That is what pull requests are for. They are not just a GitHub feature, they are part of how teams collaborate safely.
This also makes pull requests useful in internship prep and interviews. If you can explain how you forked a repo, created a branch, committed changes, pushed them, and opened a pull request, you are already speaking the language of real-world software development.
Company repo vs open source repo
A useful place to start is the difference between a company repository workflow and an open source workflow.
In a company setting, if you already have write access to the repository, the process is simpler. You can clone the company repo directly, create a branch from main, make your changes, push your branch to that same repo, and open a pull request for review. The repo belongs to the organization, but you already have permission to work inside it.
In open source, that is usually not the case. You normally do not have write access to the original repository. So before you can contribute, you create your own copy of the project on GitHub. That copy is called a fork. Then you clone your fork to your computer, make changes there, and submit a pull request back to the original project.
That one distinction clears up a lot of beginner confusion.
The three-layer model
It helps to think in three layers:
- Upstream repo: the original project owned by the maintainer or organization
- Your fork: your personal copy of that project on GitHub
- Local repo: the copy on your computer where you actually edit files
Once you understand those three layers, the rest becomes much easier.
Step 1: Install Git and make sure it works
You need:
- Git
- a GitHub account
- a terminal (Windows Terminal or macOS Terminal)
- a code editor such as VS Code
Any editor will do. The point is learning the workflow.
The workflow here uses the Git command line, which is worth learning early. After installing Git, verify it in the terminal by checking the version. The example setup uses Git, GitHub, Windows Terminal or macOS Terminal, VS Code, and a Quarto blog repository.
Step 2: Fork the repository
Go to the open source repository on GitHub and click Fork.
This creates a copy of the project under your own GitHub account. That matters because your fork is the version where you have write access. Without a fork, you usually cannot push changes to an open source project.
Step 3: Clone your fork, not the upstream repo
This is the most common beginner mistake.
You want to clone your fork, not the original upstream repository:
git clone https://github.com/your-username/repo-name.git
cd repo-name
If you clone the wrong repository, your later push may fail or go somewhere you did not intend.
Step 4: Create a branch before you change anything
Do not work directly on main. Create a feature branch first:
git checkout -b new-blog-post-on-pull-requests
This creates a new branch and switches you to it immediately.
Branching feels confusing at first, but the logic is simple: your branch is a safe workspace for your changes. It keeps your work isolated until it is ready for review.
You can confirm your current branch with:
git branch
Step 5: Make your changes locally
Now edit the files you want to change. Your change might be a documentation fix, a README improvement, a typo correction, or a small code update.
At this stage, everything is still local to your machine. You can use VS Code, Cursor, Notepad, or whatever editor you have available.
Step 6: Stage your changes
Once you have made your edits, stage the files you want to include in the commit:
git add .
Or, if you want to add only one file:
git add path/to/file
Then check the current state:
git status
This is one of the most important Git commands for beginners. Use it constantly. It shows what has changed and what Git is about to include.
Step 7: Commit with a clear message
A commit is a saved checkpoint in your branch history.
git commit -m "Start blog post on pull requests"
Your message should be short but useful. A reviewer should be able to tell what changed from the commit message alone.
If Git asks for your identity, configure it:
git config --global user.email "you@example.com"
git config --global user.name "Your Name"
GitHub also offers a privacy-protecting email option if you do not want your personal email exposed in commit metadata.
Step 8: Check your remote before pushing
Before you upload anything, confirm where origin points:
git remote -v
In an open source workflow, origin should usually point to your fork. This is a simple check, but it prevents a lot of frustration.
Step 9: Push your branch to GitHub
Now push your branch:
git push origin new-blog-post-on-pull-requests
Depending on your setup, Git may open a browser window so you can authorize the push. That is normal. Once the push succeeds, your changes are on GitHub but only in your fork.
Step 10: Open the pull request
Go to your fork on GitHub. You should see a prompt like Compare & pull request.
Click it, then write a useful title and description. Do not treat this as an afterthought. The pull request is your explanation to the maintainer. Say what changed and why.
Also, do not open a pull request too early. If your work is incomplete, it creates extra friction for maintainers. Open a pull request when your changes are actually ready for review.
What happens after you open it?
This is where real collaboration starts.
As the contributor, you usually cannot merge the pull request yourself unless you are also a maintainer. Instead, the maintainer reviews it, tests it, and may comment or request changes. That back-and-forth is normal. It is not a sign that you failed—it is part of the process.
That review loop is exactly why this skill matters for students. It teaches you how development works in real teams:
- you work in branches
- you submit changes for review
- you communicate clearly
- you revise when needed
- you avoid pushing unfinished work directly into the main codebase
Those are not optional “extra” skills. They are part of being employable as a developer.
Final takeaway
If you are still early in your GitHub journey, start small. You do not need to make a huge open source contribution on day one. A documentation fix, a blog post, or a minor improvement is enough to learn the workflow.
Once you can confidently fork a repo, clone your fork, create a branch, commit your changes, push to GitHub, and open a pull request, you are already building the kind of practical experience that helps with internships, interviews, and team-based software work.
If you want more beginner-friendly, job-focused tutorials like this, the full Industry Projects for Python course is free and built around real workflows that help students move from classroom coding to practical development: https://industry-python.thinkific.com/products/courses/industry-projects-with-python.
Top comments (0)