Your First Contribution to Someone Else's Project

Every established project has house rules, and a pull request that ignores them is closed politely and never merged — not because the code was bad, but because the maintainer has had that conversation four hundred times.

The single biggest mistake is writing code first. Open an issue, or comment on an existing one, and say what you intend to do — before you spend a weekend on it.

You cannot push to somebody else's repository, which is the point of a fork: your own copy under your own account, which you can push to, and which stays linked to the original.

Step three of that is the one everybody skips. After cloning your fork, origin is your fork and there is no reference to the real project at all. Adding it as a second remote is what lets you keep up with what the project does next.

# The whole thing, once$ gh repo fork original/project --clone$ cd project$ git remote -v# origin    [email protected]:you/project.git       (your fork)# upstream  https://github.com/original/project  (the real one — gh adds this for you) $ git switch -c fix/csv-quoting# ... work, commit ...$ git push -u origin fix/csv-quoting$ gh pr create --repo original/project --fill

A fork is a snapshot. It does not update itself, and a fork left alone for a month is a month behind — which is how a small pull request arrives full of conflicts.

# If you did not fork with gh, add the original by hand$ git remote add upstream https://github.com/original/project.git # Bring your main up to date with theirs$ git fetch upstream$ git switch main$ git merge upstream/main      # or: git rebase upstream/main$ git push origin main         # update your fork on GitHub too # Then rebase your feature branch onto the fresh main$ git switch fix/csv-quoting$ git rebase main

Two shortcuts. GitHub's web interface has a Sync forkbutton on your fork's main page, and gh repo sync does the same from a terminal.

$ gh repo sync you/project --source original/project

Rebasing your feature branch is safe here for the reason from the rebase chapter: those commits are yours, on your fork, and nobody builds on them. A force-with-lease push to your own branch updates the pull request cleanly.

Larger projects, especially company-backed ones, need a legal record that you had the right to contribute the code and are granting them a licence to it. There are two mechanisms and they are not the same thing.

# Sign off a commit$ git commit -s -m "Quote CSV fields per RFC 4180" # Adds this line to the message:# Signed-off-by: Your Name <[email protected]> # Retroactively, for the last three commits$ git rebase --signoff HEAD~3

A bot will tell you if either is required, usually within a minute of opening the pull request, with a link. It is a formality — but it is a blocking formality, and pull requests do sit unmerged for weeks because nobody read the bot's comment.

If the goal is a first contribution, code is the hardest possible starting point and not the most valuable one.

When you do want code, the good first issue label exists precisely for this and GitHub surfaces it globally. Filter for a project you actually use — familiarity with the thing is worth more than familiarity with the language.

$ gh issue list --repo original/project --label "good first issue" --state open$ gh issue list --repo original/project --label "help wanted" --state open # Say you are taking it, so two people do not do the same work$ gh issue comment 482 --body "I would like to take this if it is still open."