Your First Pull Request: A Complete Step-by-Step Guide

You already have an issue. This page is how to ship the pull request: fork, clone, branch, commit, push, open the PR.

It is not a week-1 plan. That is how to contribute to open source. It is not GitHub Issues search, Codespaces, or draft vs ready. That is how to contribute to open source on GitHub. If you still need an issue, start on a live hub, not this tutorial.

I built Help Wanted so finding work is a filter, not a gist:

• All languages: https://helpwanted.dev/
• Python: https://helpwanted.dev/language/python
• TypeScript: https://helpwanted.dev/language/typescript
• JavaScript: https://helpwanted.dev/language/javascript

The Git commands did not change in 2026. The bar did. Maintainers close unasked, AI-generated diffs. A small, tested, scoped patch still gets reviewed.

Before you type git

You need a GitHub account, Git on your machine (git --version; install from git-scm.com if that fails), and one issue you intend to finish.

If you do not have the issue yet, stop. Use how to find good first issues or the beginner projects list, pick from a hub, then come back.

Read CONTRIBUTING.md (and the code of conduct) on that repo before you fork. Note the default branch name (main is common, not universal), how they run tests, and whether they want a comment before you start. Then comment on the issue: one short note that you are taking it.

The workflow

A pull request is a request that the original project take commits from a branch on your fork.

1. Fork the repository on GitHub
2. Clone your fork
3. Add upstream (the original repo)
4. Create a branch
5. Make a small change
6. Commit and push to your fork
7. Open a pull request against the original default branch

A fork lives on your GitHub account. A clone lives on your computer. You never need write access to the original repo.

1. Fork the repository

On the original repo, click Fork. GitHub copies it to github.com/YOUR-USERNAME/repository-name.

That copy is yours. You can push branches to it. Do not edit files on GitHub yet. The work happens on a local branch.

2. Clone your fork and add upstream

git clone https://github.com/YOUR-USERNAME/repository-name.git
cd repository-name
git remote -v

origin should point at your fork. Add the original project as upstream:

git remote add upstream https://github.com/ORIGINAL-OWNER/repository-name.git
git remote -v

You should see origin (you) and upstream (them). If upstream is already there, do not add it twice.

3. Create a branch

Never commit on main (or master, or whatever the default is).

git fetch upstream
git switch main
git merge upstream/main
git switch -c fix/issue-123-short-description

If git switch main fails, the default branch is probably master or whatever CONTRIBUTING.md names. Use that.

Branch names that help reviewers:

• fix/issue-123-readme-typo
• docs/issue-123-install-steps
• test/issue-123-null-check

One issue per branch. git switch -c is the current command; git checkout -b still works.

4. Make a small change

Do what the issue asks. That is the whole job.

• Match the project’s style. If they use a formatter, run theirs.
• Run the tests they document (whatever CONTRIBUTING.md says). If you cannot run them, say so in the PR and say what you did instead.
• Do not reformat a file you did not otherwise touch.
• Do not “also” fix a nearby nit unless the issue said to.
• Do not paste a generated dump you cannot explain.

That last point is the 2026-specific part. Models will draft a patch. Maintainers can tell. A README typo on a project you do not use, a formatter-only diff, or a PR that claims to fix an issue it does not touch gets closed. If you use a model, use it as a rubber duck, then own the diff in review.

5. Commit

See what you changed before you stage it:

git status
git diff

Stage specific files, not the whole tree:

git add src/the-file-you-meant.py
git status

Then commit with an issue reference:

git commit -m "Fix typo in README installation section"

A body line such as Fixes #123 (or Closes #123) links the issue and closes it when the PR merges, if the project uses that convention. Some projects want Refs #123 instead — follow their guide.

Do not run git add .. That stages .env files, local config, or a formatter sweep. Check git status after you add.

Commit messages: imperative verb, first line short, issue number in the body.

6. Push to your fork

git push -u origin fix/issue-123-short-description

-u sets the upstream so later you can git push with no extra args. You push to origin (your fork), never to upstream — you do not have write access there.

7. Open a pull request

On GitHub, open a pull request from your branch into the original repo’s default branch. Compare across forks if the UI does not offer a banner.

This page stops at “open a PR.” Draft vs ready, the Contribute sidebar, and Codespaces are in the GitHub companion. Git does not care which button you click. The branch you pushed is the same either way.

Keep the description short: title that matches the change, Fixes #123, what you changed, how you tested it.

Before you submit:

1. Files changed — only the files the issue needed
2. Base branch is the project’s default
3. You are not committing secrets, node_modules, or a lockfile you did not mean to touch

Then create the pull request. Stay subscribed. Review comments are the rest of the contribution.

After you open it: more commits, same branch

When a maintainer asks for a change, do it on the same branch:

git add src/the-file-you-meant.py
git commit -m "Address review: rename parseConfig helper"
git push

The PR updates itself. Do not open a second PR to “nudge.”

Be patient. Volunteer maintainers are slow. If the repo was active when you picked it, wait. If you picked a dead repo, that is a hunting mistake, not a Git mistake.

Keep the fork current

Before a new piece of work, or if GitHub says the PR has conflicts:

git fetch upstream
git switch main
git merge upstream/main
git push origin main

Then merge main into your feature branch:

git switch fix/issue-123-short-description
git merge main

If Git reports conflicts, fix the files, git add them, and finish the merge. Ask on the PR if you are stuck. Do not force-push unless a maintainer told you to rebase and you know what that does.

Common Git problems

After it merges

Delete the local branch:

git switch main
git branch -d fix/issue-123-short-description

GitHub will offer to delete the remote branch. Use it.

Then pick the next issue on helpwanted.dev — or stay on the same repo if they still have labeled work. One merge is enough to learn this workflow. The second one is faster because the clone and remotes already exist.

FAQ

Do I work on main?

No. Fork, then a branch named after the issue. main on your fork is for tracking upstream.

What is the difference between fork and clone?

A fork is a copy on GitHub under your account. A clone is a copy on your disk. You clone your fork, add upstream, and open a PR from a branch you pushed to origin.

Should I use AI to write the patch?

You can use it to read code. You cannot dump a generated diff and leave. If you cannot explain the change in the PR, do not open it. Maintainers are closing that class of PR on sight.

The GitHub UI has draft pull requests. Which one do I click?

Open a PR when the change is reviewable. Draft vs ready is a GitHub product detail — see how to contribute to open source on GitHub. Git does not care. The branch you pushed is the same either way.

What if I cannot run the tests?

Say so in the PR, and say what you did instead (manual check, a smaller test, reading the surrounding tests). Do not pretend CI is optional if CONTRIBUTING.md requires it. If local setup is the actual blocker, pick a smaller issue or a docs task from the hub.

Start here

1. If you still need an issue: helpwanted.dev, Python, TypeScript, or JavaScript.
2. Read CONTRIBUTING.md, comment on one issue.
3. Fork, clone, branch, small commit, push, open the PR. Week-1 map: how to contribute to open source. GitHub buttons: how to contribute to open source on GitHub.

The commands are boring on purpose. The hard part is a scoped diff on a repo that still reviews.