Many people learn Git and then immediately ask, “How do I actually contribute to an open-source project?” The answer is that most open-source development follows a well-defined workflow that allows thousands of people to work together without interfering with each other’s changes.
This article explains the typical process used on GitHub and introduces the concepts of repositories, forks, branches, pull requests, code reviews, and contributions.
Understanding Git vs GitHub
A common point of confusion is the difference between Git and GitHub.
Git is the software installed on your computer that tracks changes in files and manages version history.
GitHub is a website that hosts Git repositories online and provides collaboration tools such as issue tracking, code reviews, pull requests, discussions, and project management.
You can use Git without GitHub, but GitHub makes it much easier to collaborate with other developers.
Finding a Project
Many developers begin by contributing to projects they already use.
Look for:
- Projects you use regularly
- Documentation improvements
- Bug fixes
- Beginner-friendly projects
- Small utilities written in languages you know
Many repositories label beginner tasks with tags such as:
- good first issue
- beginner
- help wanted
- documentation
These issues are specifically intended for new contributors.
Cloning a Repository
The first step is downloading a copy of the project’s source code.
Example:
git clone https://github.com/project-owner/project-name.git
Move into the project directory:
cd project-name
You now have a complete local copy of the project.
Understanding Forks
Many projects do not allow direct changes to the main repository.
Instead, you create a fork.
A fork is your own copy of someone else’s repository on GitHub.
The process works like this:
- Visit the repository on GitHub.
- Click the Fork button.
- GitHub creates a copy under your account.
- Clone your fork to your computer.
Example:
git clone https://github.com/yourusername/project-name.git
This allows you to make changes without affecting the original project.
Creating a Branch
Never work directly on the main branch.
Create a branch for each change.
Example:
git switch -c fix-spelling-error
Or:
git checkout -b fix-spelling-error
The branch name should describe the purpose of the change.
Examples:
fix-login-bug
update-documentation
improve-error-message
add-config-option
Working on separate branches keeps changes organized and makes reviews easier.
Making Changes
After creating a branch, modify the files needed for your fix or feature.
Examples include:
- Correcting a typo
- Fixing a bug
- Improving documentation
- Updating configuration examples
- Adding a feature
Make small, focused changes whenever possible.
Large changes are harder to review and more likely to be rejected.
Testing Your Changes
Before committing anything, test your work.
If you modified code:
- Compile it
- Run it
- Verify that the bug is fixed
- Ensure nothing else broke
If you modified documentation:
- Check spelling
- Verify commands
- Confirm links work
Testing demonstrates professionalism and respect for the maintainers’ time.
Committing Changes
Stage your changes:
git add .
Create a commit:
git commit -m “Fix typo in installation guide”
Good commit messages are:
- Short
- Clear
- Specific
Examples:
Fix memory leak in parser
Correct installation instructions
Update README examples
Improve error handling
Avoid vague messages such as:
stuff
changes
fixes
update
Pushing Your Branch
Upload your branch to GitHub:
git push origin fix-spelling-error
GitHub now contains your proposed changes.
Creating a Pull Request
A pull request (PR) is a request asking maintainers to merge your changes into their project.
On GitHub:
- Open your fork.
- Click Compare & Pull Request.
- Write a clear explanation.
- Submit the pull request.
A good pull request explains:
- What changed
- Why it changed
- How it was tested
Example:
“This pull request corrects a typo in the installation instructions. The command previously referenced the wrong package name. The documentation was reviewed and tested on Ubuntu 24.04.”
Code Review
After submitting a pull request, maintainers review the code.
They may:
- Approve it
- Ask questions
- Request modifications
- Reject it
This is normal.
Even experienced developers receive review comments.
Review comments are intended to improve the project, not criticize the contributor.
Updating a Pull Request
Suppose a reviewer asks for changes.
Modify the files.
Commit again:
git add .
git commit -m “Address review comments”
Push again:
git push
The pull request updates automatically.
No new pull request is needed.
Keeping Your Fork Updated
The original project continues changing while you work.
Add the original repository as an upstream source:
git remote add upstream https://github.com/project-owner/project-name.git
Fetch updates:
git fetch upstream
Merge updates:
git merge upstream/main
This keeps your fork synchronized with the original project.
Reading Issues
Most projects use an issue tracker.
Issues often contain:
- Bug reports
- Feature requests
- Documentation tasks
- Questions from users
Reading issues is one of the best ways to learn how a project works.
You can often find simple tasks that make excellent first contributions.
Starting with Documentation
Many new contributors assume they must write code.
In reality, documentation contributions are extremely valuable.
Examples:
- Correcting typos
- Improving tutorials
- Clarifying instructions
- Adding examples
- Updating screenshots
Documentation changes teach the contribution workflow without requiring deep knowledge of the codebase.
Contributing to Large Projects
Projects such as the Linux kernel use a more advanced process.
Instead of GitHub pull requests, many kernel developers submit patches through mailing lists.
The workflow is generally:
- Clone the source code.
- Create a branch.
- Make changes.
- Test thoroughly.
- Create a commit.
- Generate a patch.
- Email the patch to maintainers.
- Respond to review comments.
- Submit revised versions if needed.
Although the tools differ, the underlying process remains the same:
Make a change, test it, submit it for review, and improve it based on feedback.
Common Beginner Mistakes
- Making huge changes in a single pull request.
- Not testing code before submission.
- Ignoring project contribution guidelines.
- Working directly on the main branch.
- Writing unclear commit messages.
- Taking review comments personally.
- Attempting complex features before understanding the project.
Most maintainers appreciate small, well-tested improvements far more than ambitious but unfinished work.
A Realistic First Contribution Plan
Week 1:
Learn Git basics and GitHub navigation.
Week 2:
Clone several repositories and explore their structure.
Week 3:
Find a documentation issue and submit a small pull request.
Week 4:
Fix a minor bug or improve a small feature.
Month 2:
Begin reading source code and participating in project discussions.
Month 3:
Start contributing regularly to a project you enjoy.
Consistency is more important than the size of individual contributions.
Final Thoughts
Open-source development is not about being the smartest programmer in the room. Most successful contributors simply show up consistently, communicate clearly, test their work, and remain willing to learn.
Your first contribution may be a typo fix, a documentation update, or a one-line code change. Many professional developers started exactly that way. Over time, those small contributions accumulate into experience, confidence, and a deeper understanding of how real-world software is built.