Find the file and branch before changing it
Open the repository and note its owner, name, and selected branch. Browse to the README file rather than assuming the text on the repository landing page comes from the root. GitHub can display a README from a recognized location elsewhere in the repository.
For a small correction, open that file's pencil editor. GitHub's file-editing documentation describes editing, previewing, and choosing a new branch when committing from the default branch. Repository permissions and branch protections can restrict the available route. If the file cannot be edited directly, use the project's permitted contribution workflow; do not weaken protection for a documentation fix.
Correct one link with a verifiable target
Consider this original fictional repository layout:
README.md
docs/
setup.md
contributing.md
The README currently contains:
Read the [setup instructions](setup.md) before changing the code.
From a root README, that link points to a root-level file that the example does not have. Correct it to:
Read the [setup instructions](docs/setup.md) before changing the code.
If the maintained README instead lives inside docs/, the relative path changes. Resolve the link from the file's real location, and check exact filename case. A plausible directory tree in a draft is not evidence that the file exists in your repository.
Keep this fix small. Moving headings, rewrapping unrelated paragraphs, and changing the onboarding instructions at the same time makes it harder for a reviewer to confirm the path correction.
Preview the Markdown, then inspect the diff
Choose Preview above the edited content. Confirm the link label reads naturally and the destination opens the expected setup document on the intended branch. If GitHub's navigation leaves the editor, preserve your unsaved text first or open the destination in a separate tab.
Inspect the changed lines as well as the rendering. A page can look unchanged while the link target is still wrong. Conversely, an unmatched backtick or fence can turn following prose into code even though you only meant to update a URL. For syntax help, use the GitHub README template when the content needs a larger redesign; a single broken path does not require replacing the whole README.
Put the correction on a review branch
When your repository workflow permits saving the change, choose Commit changes and give the commit a concrete description, such as:
Fix README link to docs/setup.md
Choose a new branch for review, for example docs/fix-setup-link, rather than committing straight to the default branch. If you are contributing to a repository you cannot write to, GitHub's editor can guide you through a fork and proposed change instead. Follow the organization's contribution rules before creating external artifacts.
In the pull request, verify both branch selectors. The base is where the change would land; the compare branch contains your correction. GitHub's pull-request instructions explain this direction. Check Files changed for the one intended path correction before asking anyone to review.
An appropriately small description is:
The root README linked to setup.md, but the setup document lives at
docs/setup.md. This changes the target to the existing file.
Validation: previewed the README and opened the corrected link.
Use that validation sentence only after doing those checks. If you have only prepared the edit locally, describe the remaining checks instead.
Confirm the change where readers will see it
A saved commit on your branch does not change the default branch's README. After the normal approval and merge process, open the default branch and follow the link again. Keep the repository file as the authoritative document; an HTML reading copy neither commits this edit nor merges its pull request.