Choose the passage you need to support
Suppose you are checking an installation statement in your own project’s public README before mentioning it in an article. Find the exact passage and its nearby conditions. A repository title or profile biography does not substitute for the file containing the statement.
Keep the task limited to the document. You do not need to run the project, inspect personal contact information or treat a contributor’s account as proof of a private identity.
Replace the changing branch view with a version link
GitHub explains that an ordinary file view usually shows the current head of a branch, so its contents can change as commits arrive. While viewing the file, pressing y changes the URL to a permalink that uses a specific commit instead of the branch name. Source
Copy the URL actually displayed after that action. Reopen it and confirm that it shows the same file and passage. Do not invent a commit identifier or construct a citation from a search preview you have not opened.
Keep a separate note if you also want the current branch address. The version link answers “what wording did I inspect?” while the branch view lets you check what the project presents now.
Record enough context for another reader
| Field | Record from your inspection | Purpose |
|---|---|---|
| Repository and file | The actual project and file path | Identify the document being cited |
| Commit identifier | The version in the copied permalink | Distinguish this snapshot from later edits |
| Supporting passage | A short excerpt or faithful summary | Limit the claim to the inspected wording |
| Nearby conditions | Version, environment or feature limits | Avoid dropping a qualification |
| Access date | When you opened the source | Separate your review time from publication history |
For an illustrative README that says an export feature is experimental, the supported statement retains “experimental.” A stable URL does not justify rewriting it as a tested guarantee. This example illustrates citation practice; it is not a report about a real repository.
Decide whether an old statement is still relevant
If the current branch differs, retain both observations: the earlier version you cited and the current wording you actually opened. Do not silently replace an older citation while continuing to describe it as the same review.
A file can contain plans, examples or outdated instructions. Attribute those statements to the project rather than claiming you independently tested the implementation. If access later fails, record that limitation; a version identifier is not a promise of permanent hosting or permission.
This is also separate from a signed-commit badge. The GitHub Verified-badge guide addresses that different signal. For a broader synthesis of public documents, use the AI source-review checklist and retain the exact version each material claim relies on.