Your first pull request: step by step

Step 1. Pick an issue

Find a project you actually use and look at its open issues. Search for labels like "good first issue". If there are none, start with the documentation: an inaccuracy, an outdated example, a missing explanation.

Before starting, comment on the issue that you're taking it. It's basic courtesy and insurance against someone doing the same work.

Step 2. Read the guidelines

Nearly every project keeps a contribution guide at the root. It explains how to format changes, how to name branches and what a description should contain. Half of all rejected changes come from people who never opened it.

Step 3. Fork and branch

Fork the project, clone your copy and create a branch for the task:

git clone <your fork>
cd <project>
git checkout -b fix-docs-typo

Keep the branch name short and descriptive. Don't work on the main branch.

Step 4. Make the change

One change, one purpose. Resist the urge to also reformat the whole file: such changes are hard to review and often rejected wholesale.

Check that the project builds and the tests pass. How to run them is usually in the same guide.

Step 5. Write the commit

git add .
git commit -m "docs: fix the run example in README"

The message should explain what was done. "fix" or "update" say nothing.

Step 6. Push and open the request

git push origin fix-docs-typo

The project page will then offer to open a pull request. In the description write: what was wrong, what you changed, how to verify it. If it relates to an issue, link it.

Step 7. Respond to review

You'll almost certainly be asked to change something. That isn't a rejection, it's the normal process.

Make the fixes on the same branch — the request updates itself. Reply to every comment: fixed, or explain why you did it differently.

Step 8. It gets merged

Congratulations: you now have public proof that you can work with someone else's code under someone else's rules. You can point to it on a CV, and it's verified in one click.

If it isn't merged

It happens. Plans change, or a maintainer disagrees with the approach. Ask what you could have done differently and try elsewhere. The experience stays with you either way.