Git Course 0%

The project page tour

Intermediate GitLab UI ≈ 10 min

Before this lesson

What you will learn

  • What each section of the left sidebar holds
  • The repository views: files, history, blame, branches, tags, compare
  • The fastest ways to find a file, a commit or a change

After this lesson you can

  • I can find anything in a GitLab project without hunting

Why this matters

A GitLab project has a lot of pages, most of which you will never use. Ten minutes spent learning which five matter turns the interface from an obstacle into the fastest way to answer questions about a codebase, often faster than the terminal.

The left sidebar

The sidebar groups everything by what you are trying to do. Items you use often can be pinned to the top, and the whole sidebar changes depending on whether you are looking at a project, a group or your own work.

Section Holds You will use
Manage Activity, Members, Labels Members (lesson 9.3)
Plan Issues, Issue boards, Milestones, Iterations, Wiki Issues and boards, constantly (lesson 9.6)
Code Merge requests, Repository, Branches, Commits, Tags, Compare revisions, Snippets Merge requests and Repository, constantly
Build Pipelines, Jobs, Pipeline schedules, Artifacts Pipelines, when something is red (lesson 9.10)
Deploy Releases, Packages, Container registry Releases (lesson 9.9)
Operate Environments, Kubernetes Rarely
Monitor Incidents, Error tracking Rarely
Analyze Value stream, CI/CD analytics, Insights Rarely
Settings General, Repository, Merge requests, CI/CD, Access tokens Only with Maintainer or above

Two shortcuts worth memorizing: g then m jumps to merge requests, and the top bar's Search or go to finds projects, issues and merge requests from anywhere.

The repository views

Code → Repository is the file browser, and it is where most of a non-developer's time goes. Each view answers a different question:

View Answers Terminal equivalent
Repository (file list) What is in this project? ls, git switch
A file What does it say now? opening the file
History (on a file) When and why did this file change? git log -- <file>
Blame (on a file) Who last changed each line, and in which commit? git blame <file>
Commits What has been happening? git log
Branches What is being worked on, and how stale is it? git branch -a
Tags Which versions exist? git tag
Compare revisions What changed between these two points? git diff a...b

Three details that save time:

  • The branch selector at the top left of the file list switches which branch you are browsing. Reading a file on main when the change you want is on a branch is a common few minutes wasted.
  • Blame has a history slider. Clicking the arrow beside a line's commit re-blames the file as it was before that change, which is how you walk back past a reformatting to the commit that actually introduced a sentence.
  • Press y on a file page to turn the URL into a permanent link to that exact commit. A link without it points at "whatever the branch says today", which is a poor thing to paste into an issue.

Finding things

You want Do this
A file whose name you know Press t on the repository page and type it
A phrase anywhere in the code The search box, scoped to the project, then the Code tab
The commit that introduced a sentence Blame the file, then walk back with the history slider
Everything one person did last week Code → Commits, then filter by author
What changed since the last release Code → Compare revisions, from the tag to main

How to do it

Everything above has a local equivalent, and the terminal wins when you want to combine things:

Terminal
$ git log --oneline -- docs/faq.md
$ git blame docs/faq.md
$ git diff v1.2.0...main --stat

The web wins when you want to link to something, when you are on a machine without a clone, or when you want blame with a clickable history.

Common mistakes

  • Reading a file on the wrong branch. The selector is easy to miss; the branch name is always shown above the file list.
  • Linking to a file without a permalink. The link rots as soon as the branch moves. Press y first.
  • Assuming Blame names the author of an idea. It names the last commit that touched the line, which may be a reformatting (lesson 5.5).
  • Hunting through the sidebar instead of using Search or go to and the keyboard shortcuts.
  • Expecting a missing feature to be a bug. Issues, wiki and other features can be switched off per project in the settings.

Try it yourself

Goal: answer three questions about your own project using only the web interface.

  1. Open your practice project and find docs/faq.md through the repository browser.
  2. Use Blame to find which commit last changed the first answer, and open that commit.
  3. Press y on the file page and note how the URL changes.
  4. Open Code → Branches and note the ahead and behind numbers.
  5. Use Code → Compare revisions to compare main with any branch you still have.

Expected result: you found a commit from a line of prose, produced a permanent link, and compared two branches, all without the terminal.

Show solution

The permalink in step 3 replaces the branch name in the URL with a commit hash, which is why it keeps working after the branch moves. That single habit makes links pasted into issues and chat still correct a year later.

Check yourself

1. Which sidebar section holds merge requests, the repository browser and the branch list?
2. You want to link to a specific line of a file so the link still works next year. What do you do?
3. Blame shows a colleague on a line you know someone else wrote. Why?

Key terms

Repository (repo) Commit Branch Tag Log

Related