The repository page tour
Beginner GitHub UI
Why this matters
You will spend more time reading repositories than writing in them: checking what a change did, finding the file that documents something, seeing whether a fix shipped. The page is dense, and ten minutes spent learning it saves a great deal of scrolling.
The tabs
| Tab | What it holds | You will use it |
|---|---|---|
| Code | Files, branches, tags, releases, the README | Constantly |
| Issues | Work items and bug reports (lesson 10.6) | Often |
| Pull requests | Proposed changes (lesson 10.7) | Constantly |
| Actions | Workflow runs and logs (lesson 10.10) | When something is red |
| Projects | Boards and tables over issues | If your team uses them |
| Wiki | Free-form pages, if enabled (lesson 10.11) | Sometimes |
| Security | Advisories, Dependabot, secret scanning | Rarely, but know it exists |
| Insights | Contributors, traffic, dependency graph, Network | For "what happened here?" |
| Settings | Everything configurable; Admin only | When you own it |
Tabs can be hidden per repository, so a repository with no Wiki tab has it switched off rather than empty.
The Code tab, part by part
The branch selector, top left of the file list, switches which branch or tag you are looking at. Everything below it, including the README, is that branch's version. Reading a file on a feature branch and thinking it is main is a classic and quiet mistake.
The commit bar above the file list shows the last commit that touched the tree, its author and its status check. Clicking the commit hash opens it; clicking the clock icon opens the full history.
The file list shows, for each entry, the last commit that changed it and when. That is a fast way to spot the file nobody has touched for three years.
The right sidebar carries the description, topics, the licence, and links to Releases (lesson 10.9), Packages and Contributors.
The Code button above the file list holds the clone addresses, HTTPS and SSH, and the Download ZIP option. It is also where Open with GitHub Desktop and Codespaces live.
Inside a file
Opening a file gives you five controls worth knowing:
| Control | Does |
|---|---|
| Edit (pencil) | Edit in the browser, committing to a branch (lesson 7.8) |
| Blame | Shows which commit last changed each line, and why |
| History | Every commit that touched this file |
| Raw | The plain file, useful for copying or curl |
| Code / Preview | For Markdown, the source or the rendered page |
Blame is the single most useful button on the site for a non-developer: it turns "why does the guide say this?" into a commit, a pull request, a discussion and usually an answer.
Four shortcuts
| Key | Does |
|---|---|
| t | Fuzzy file finder: start typing a filename from anywhere in the repository |
| . | Opens the repository in the web editor (lesson 10.11) |
| s or / | Focus the search box |
| ? | The full shortcut list |
t is worth learning today. It finds a file in a large repository in about two seconds, which is faster than clicking through directories and much faster than asking.
Search
The repository search box searches this repository; the one in the header searches everything you can see. Two qualifiers cover most needs:
path:docs windows
repo:northwind-trails/trailguide is:issue is:open label:documentationCode search matches the default branch. If you cannot find a string you know exists, check whether it only exists on a branch.
How to do it
Everything the page shows, Git can tell you locally, usually faster:
$ git log --oneline -3 -- docs/getting-started.md
$ git blame -L 20,30 docs/getting-started.mdThe advantage of the web page is the link between a line and the pull request that changed it; the advantage of the terminal is speed and no network.
The Command Palette's Go to File is the equivalent of t. The GitLens extension adds inline blame; the built-in Timeline view in the Explorer shows a file's commits.
Navigate → File is the file finder. Git → Show History on a file, and Annotate with Git Blame in the gutter's context menu, are the blame and history views.
The same regions with different names: Code for the file tree, Plan for issues, Code → Merge requests, Build for pipelines, and Manage → Activity for what has happened. See lesson 9.4.
- Check the branch selector before reading anything; it decides what every file below shows.
- Press t to find a file by name, . to open the web editor, ? for the rest.
- On a file, use Blame to find out why a line says what it says.
- Use the sidebar's Releases to see what shipped, and Insights → Network to see the branch shape.
- Watch, top right, controls notifications for this repository; Fork copies it to your account; Star is a bookmark.
Common mistakes
- Reading a file on the wrong branch and reporting a bug that was fixed last week.
- Hunting through folders instead of pressing t.
- Ignoring Blame, then asking a person what a commit could have told you.
- Assuming a missing tab means the feature is broken. It is switched off in Settings.
- Searching code and forgetting that search covers the default branch.
Try it yourself
Goal: answer three questions about a repository using only the page.
- Open any public repository you use, or your practice one.
- Press t and open
README.mdwithout clicking through folders. - Use Blame on one line of it and find the pull request that introduced it.
- Switch the branch selector to another branch and confirm the file list changes.
- Open Insights → Network and describe the branch shape in one sentence.
Expected result: you found a file by name, traced a line to a discussion, and saw the branch structure without cloning anything.
Show solution
Step 3 is the one to keep. Blame answers "why is this like this" better than any person's memory, because it links the line to the commit, the commit to the pull request, and the pull request to the argument that produced it.