Your first pull request, step by step

A pull request is how you propose a change to a project you do not own. This guide follows the usual path from start to finish. The commands are shown in words; GitHub Desktop and most editors have a button for each step.

The contribution loop

• Fork: on the project's GitHub page, choose Fork. This makes your own copy of the repository under your account.
• Clone: download your fork to your computer with git clone and the URL of your fork.
• Branch: create a new branch for this one change, named after what it does, for example fix-login-typo. Keep each pull request to one idea.
• Change and test: edit the code, then run the project's tests as its README describes.
• Commit: save a snapshot of your change with a short message that says what changed and why.
• Push: upload your branch to your fork on GitHub.
• Open the pull request: GitHub offers to open one after you push. Describe what you changed, why, how you tested it, and link the issue.

Responding to review

Requested changes are a normal part of review, not a rejection. Read every comment. If you agree, make the change, commit, and push to the same branch: the pull request updates by itself. If you are unsure, ask a specific question. When you have addressed a comment, reply so the reviewer knows.

What automated checks are

Many projects run checks automatically on every pull request, often called CI. They run the tests and look for formatting problems. A red check means something failed: open its details, read the first error, fix it locally, and push again.

Good habits

• Small, focused pull requests are reviewed faster than large ones.
• Never include passwords, tokens, or personal data in code or commits.
• If you used an AI assistant, follow the program's AI policy and make sure you understand every line you submit.