If you’re learning to code and looking to build your programming portfolio, you’ve probably heard people talk about contributing to open source projects on GitHub. It sounds like a great idea—real-world experience, public contributions, and a chance to work with other developers.
But if you’re just starting out, it can also feel completely overwhelming.
Where do you even begin? How do you avoid breaking things? What if your code isn’t good enough?
Take a deep breath—this guide is for you. I’ll walk you through how to ease into the world of open source, one step at a time, even if you’re brand new to GitHub and programming in general.
Step 1: Set Up Git and GitHub
Before anything else, you need two things:
- A GitHub account (sign up here).
- Git installed on your computer (download Git here).
It’s usually pretty easy to utilize Git source control, especially in Visual Studio-based IDEs – just go to the source control window tab and follow the instructions. However, it also doesn’t hurt to learn it the old fashioned way through the Git terminal, just in case you don’t have access to an IDE that supports Git natively. For example, open your terminal/command prompt and run:
git config –global user.name “[Your Name]”
git config –global user.email “[you@example.com]”
This connects your name and your email to commits in the future. In Visual Studio, you can simply sign into GitHub using the app.
Step 2: Understanding the GitHub Ecosystem
I don’t want to spend too much time dawdling on a GitHub 101, since this article is specifically about contributing to other projects. But there are a few vocab words you have to know if we’re to go any further:
- Repository (repo): The project’s original files. Say we made a game where a frog crosses a road, and you level up each time you successfully get the frog across: the source files of that game would be located here.
- Issue: The method by which users can report problems with a project. Let’s say there’s an issue with our frog game where users can’t get past level 21 – this is the issue.
- Branch: A “sandbox” version of our project. In Git parlance, the “main” branch is the production branch – in other words, what your users actually use to play the game. If we want to figure out the level 21 bug, we’d rather do it in a “sandbox” version that only we can play, therefore we don’t interrupt other users’ experiences. We typically do this by “forking” the repository, then creating a branch on the fork. Don’t worry, this is explained later!
- Pull Request (PR): A request to merge your “sandbox” branch into the “main branch”. We’d do this after we successfully fix the issue with level 21 – the main developers then look at your branch to make sure it doesn’t break anything else on accident, and if it’s all good they’ll submit the changes!
If any of this sounds confusing, don’t worry—you’ll get used to it as you go!
Step 3: Explore and Find Beginner-Friendly Projects
I have good news: You’re not the first person to realize that contributing to GitHub repos is a daunting first step. In fact, there’s an entire culture that has developed among GitHub users to help people get into the space.
Within Github, there are three tags that any project can use in order to get the help of rookie programmers:
- good first issue
- beginner
- help wanted
Originally defined by the community itself, it’s now become a built-in feature of GitHub, allowing such tags to be very easily tracked across the entire website. Because of this, there’s several databases where you can easily find active issues. They are:
- Up For Grabs
- Good First Issues
- CodeTriage
- First Contributions
- Good First Issue (different website!)
Pick a project that interests you—even something small or simple is a great place to start!
Step 4: Fork and Clone the Repository
Once you find a project you’d like to contribute to:
- Fork it: Click the “Fork” button at the top of the repo page. This creates your own copy under your GitHub account. This is the “sandbox” version I was talking about earlier!
- Clone it: Download the project to your computer:
git clone https://github.com/your-username/project-name.git
This gives you access to editing the files, and automatically populates your changes to Git (though you’ll still need to commit them later!)
Step 5: Create a New Branch for Your Changes
Now, while we do have a copy of the code that’s safe to mess with, we still want to make a new branch within our fork to make it easier for when we submit to the original repo. In order to to that, we need to create a new branch:
cd project-name
git checkout -b my-new-branch
This will create a branch safe and away from the production code, and automatically switch you onto that branch. Now the real fun can begin!
Step 6: Make a Small Change
The best way to start in open source is by making small – perhaps even bland – changes to code. This often means not even writing code at all! A few classic first-time contributions include:
- Fix a typo in the README or other documentation.
- Add or improve a comment in the code.
- Add a missing semicolon (even if just for aesthetics).
- Update a variable or function’s name for clarity (though take in mind you’ll have to make sure every instance is fixed!)
These kinds of “low-stakes” changes help you get comfortable with the workflow, allowing you to worry about just the contribution process rather than your programming skills.
Step 7: Commit and Push Your Work
After editing, you can save your files to the repo by running:
git add .
git commit -m “Brief message about what you changed”
git push origin my-new-branch
This uploads your changes to your fork on GitHub!
Step 8: Submit a Pull Request
On your fork’s page, GitHub will suggest making a pull request to the original repo with your changes. Click “Compare & pull request”, and it will ask you to write a description for your changes. Try to include:
- What you changed
- Why you changed it
- The issue number, if you’re fixing a specific issue
Once that’s done, press “Create pull request”—and congrats! You’ve just submitted your first PR.
Step 9: Receive Feedback and Learn
Now you play the waiting game. It might be awhile until you hear back about your PR, and when you do, maintainers might ask for changes or even straight up reject you. That’s normal!
In the words of entrepreneur Sam Zell, “the number one skill of any successful person is to take rejection with indifference”. Remember to take PR rejections on the chin, and either correct your PR or move on to the next commit. There are hundreds of thousands of repos out there, and soon enough you’ll get used to the process like it’s nothing.
Bonus: Engage with Issues
Now, fixing issues isn’t the only meaningful way to contribute to open source. You’ll notice that issues on GitHub are made like forum posts – they start with a topic, and people can reply below them. In addition, some repos might have Discords or other external communities where people can talk about the project. This is where non-technical folks can shine! Give more information on issues, help triage work, and build a deeper understanding of the product to help with documentation – open source communities are looking for these skills, too!
