What you will achieve

By the end of this tutorial you will have forked an open-source repository, made a small change on a feature branch, opened a pull request, responded to feedback, and seen your work merged. The pattern works for any GitHub-hosted project; GitLab and Bitbucket are nearly identical.

Prerequisites

• Git installed (git --version shows 2.30 or later).
• A GitHub account.
• An SSH or personal access token configured for pushing.
• A target repository - a docs typo or "good first issue" is ideal for practice.

Step 1: fork the repository

On GitHub, navigate to the project and click "Fork". This creates a copy under your account.

git clone [email protected]:yourname/project.git
cd project

Step 2: add upstream as a remote

git remote add upstream [email protected]:original-owner/project.git
git remote -v
# origin    your fork
# upstream  the source

Step 3: sync from upstream

git fetch upstream
git checkout main
git merge upstream/main --ff-only
git push origin main

Step 4: create a feature branch

git checkout -b fix/typo-in-readme

Use a descriptive name. Avoid fix-stuff; prefer fix/install-section-typo.

Step 5: make the change

Open the file in your editor, make the fix, save.

git status                 # see what changed
git diff                   # review the change
git add README.md
git commit -m "Fix typo in installation section"

Step 6: push your branch

git push -u origin fix/typo-in-readme

-u sets upstream tracking; future git push calls do not need arguments.

Step 7: open the pull request

The push output usually includes a URL. Open it. Or use the CLI:

gh pr create --title "Fix typo in installation section" \
  --body "Fixes a small typo where 'isntall' should read 'install'."

Fill in the description honestly: what changes, why, how you tested. Keep it short for a typo PR.

Step 8: respond to feedback

A reviewer comments: "Could you also fix the same typo in CONTRIBUTING.md?" Make the change locally:

git add CONTRIBUTING.md
git commit -m "Fix same typo in CONTRIBUTING"
git push

The PR updates automatically. Reply to the comment to acknowledge.

Step 9: handle CI failures

If CI is red, click through to the failed run, identify the issue, fix locally, push again. Treat CI as a partner, not an obstacle.

Step 10: merge

Once approved and CI green, the maintainer (or you, depending on permissions) merges. The PR closes; your fork's branch can be deleted.

gh pr merge --squash --delete-branch
git checkout main
git fetch upstream
git merge upstream/main --ff-only
git push origin main
git branch -d fix/typo-in-readme

Common newcomer pitfalls

• Working directly on main - always branch.
• Bundling unrelated changes in one PR - keep PRs focused.
• Pushing without testing locally - reviewers' time is precious.
• Force-pushing to main - never.

What you have learned

The fork-branch-PR loop scales from one-line typos to multi-thousand-line features. The mechanics are the same; only the rigour around testing, description, and review-response increases. You now have the muscle memory for participating in any open-source project.