Pull Request: How to contribute to open projects

What is a Pull Request

A Pull Request is a request to include your changes in the main branch of the project. Imagine that you found an interesting open-source project, found a bug in it or came up with an improvement. You can't directly change the code in someone else's repository, but you can suggest your changes through a PR.

The process looks like this: you create a copy of the project, make changes in your version, and then ask the project owner to "pull" your changes to their version. Hence the name — Pull Request.

Preparing to create a Pull Request

Before you start making changes, it is important to prepare properly.

Study the project

Take the time to study the project you want to contribute to. Read the README file, study the code structure, and look at the existing Pull Requests — both open and already closed. This will help you understand the project's coding style and change requirements.

Find the CONTRIBUTING file

Many projects have a CONTRIBUTING.md file with contribution rules. It may describe code requirements, the process of creating a PR, setting up the development environment, and other important information. Be sure to follow these rules.

Check Issues

Before you start, check the Issues section. Perhaps someone is already working on a similar task, or your idea has already been discussed. If you want to fix a bug or add a new feature, it is better to first create an Issue and discuss it with the maintainers.

Fork and clone the repository

The first technical step is to create a fork of the project.

Create a fork

On GitHub, this is done with a single "Fork" button in the upper right corner of the repository page. Fork creates a copy of the repository in your account, where you can freely experiment.

Clone the fork

Now clone your fork to the local machine:

git clone https:// github.com/your-username/project-name.git
cd название-проекта

Add upstream remote

To synchronize your fork with the original repository, add it as upstream:

git remote add upstream https:// github.com/owner/project-name.git

Now you have two remotes: origin (your fork) and upstream (the original repository).

Creating a branch for changes

Never work directly in the main or master branch. Always create a separate branch for each task:

git checkout -b fix-navigation-bug

The name of the branch should be descriptive and reflect the essence of the changes. Good examples: feature-add-dark-mode, fix-login-error, docs-update-readme.

Making changes

Now you can start working on the code.

Follow the project style

Use the same coding style as in the project. Pay attention to indentation, variable naming, and file structure. Many projects use linters and formatters — run them before committing.

Make atomic commits

One commit is one logical change. This simplifies code review and makes it easy to roll back changes if necessary. Commit messages should be informative:

git add .
git commit -m "Fixed a bug with navigation freezing when scrolling quickly"

Bad message: "corrections" or "fix". Good: describes what exactly was done and why.

Write tests

If the project uses tests, be sure to add tests for your code. Also make sure that all existing tests pass:

npm test
# or
pytest

Creating a Pull Request

When the changes are ready, send the branch to your fork:

git push origin fix-navigation-bug

Now on GitHub in your fork, a "Compare & pull request" button will appear. Click it.

Fill in the PR description

Description Pull Request is your chance to explain what you did and why. A good description includes:

What has changed: brief description of the changes.

Why: explanation of the reason for the changes, link to the Issue if any.

How to test: instructions for checking changes.

Screenshots: if the changes affect the UI, add screenshots before and after.

Example description:

# # Description
Исправлен баг с зависанием навигационного меню при быстрой прокрутке страницы.

# # Related Issues
Closes #234

# # Changes
- Добавлен debounce для обработчика скролла
- Оптимизирован расчёт позиции меню
- Добавлены unit-тесты для новой логики

# # Testing
1. Откройте страницу с длинным контентом
2. Быстро прокрутите вниз и вверх
3. Навигация должна плавно следовать за скроллом без задержек

Code review process

After the PR is created, the code review process begins.

Be prepared for edits

Maintainers may request changes. This is normal and does not mean that your code is bad. Code review helps improve the quality and maintain the consistency of the project.

Reply to comments

If the reviewer left a comment, please respond to it. If you agree with the comment, make the necessary changes. If you do not agree, argue your position politely and constructively.

Make edits to the same thread

All additional commits to your branch will automatically be added to the PR:

# make changes
git add .
git commit -m "Code review comments taken into account: improved error handling"
git push origin fix-navigation-bug

Sync with main branch

While the review is in progress, the main branch of the project may go ahead. It is important to keep your branch up to date:

# get changes from the original repository
git fetch upstream

# switch to main
git checkout main

# we update our main
git merge upstream/main

# we return to our thread
git checkout fix-navigation-bug

# merge changes from main
git merge main

If there are conflicts, resolve them and commit.

Common mistakes and how to avoid them

Too much PR

One PR should solve one problem. If you fixed a bug and added a new feature at the same time, split it into two separate PRs. Large PRs are difficult to review and are less likely to be accepted.

Changes in other people's files

Do not change the formatting or style in files that are not related to your task. This creates noise in PR and complicates the review.

No description

PR without a description or with a "fix" description is unlikely to be accepted. Take the time to write a normal description.

Ignoring CI/CD

If automatic checks (tests, linters) are configured in the project, make sure they pass. PRs with failing tests will not be considered.

After PR acceptance

When your PR is accepted and merged into the main branch, you can delete your working branch:

# remove locally
git branch -d fix-navigation-bug

# remove on GitHub
git push origin --delete fix-navigation-bug

Update your fork:

git checkout main
git pull upstream main
git push origin main

Tips for beginners

Start small

Don't try to do a big refactoring right away. Start with simple tasks: correcting typos in the documentation, minor bugs, adding examples. This will help you get acquainted with the process without unnecessary stress.

Look for the "good first issue" tags

Many projects mark tasks suitable for beginners with special tags: good first issue, beginner friendly, help wanted. Start with them.

Don't be afraid to ask questions

If something is not clear, ask in the Issue or in the project chat. The open-source community is usually friendly to beginners who are trying to figure things out.

Be patient

Maintainers often do this in their free time. Your PR may not be viewed immediately — this is normal. If more than a week has passed, you can politely remind them about yourself.

Open-source etiquette

Be polite

Communicate respectfully, even if you disagree. Remember that there is a real person on the other side of the screen.

Take criticism constructively

Code review is not a criticism of you as a developer, but a way to improve the code. Take comments as an opportunity to learn something new.

Thank for help

If you were helped to deal with the problem or given time for a review, thank them. This motivates people to continue investing time in the project.

Conclusion

Creating Pull Requests is a skill that develops with practice. The first PR may seem daunting, but with each subsequent process it becomes easier and more natural. Don't be afraid to make mistakes — that's how we learn.

Participation in open-source projects not only improves your technical skills, but also opens doors to the developer community, helps build a portfolio and gain experience with real projects. Start small, be patient and attentive to details — and soon you will become a confident contributor.

Code is an educational platform for beginner developers, where you will find easy-to-understand courses on programming in Python, JavaScript, HTML, CSS and other popular technologies.

Join our Telegram channel, where we share useful articles, analyze complex concepts in simple language and help beginners take their first steps in the world of development.