View GitLab Commit History and Branch Info on Android

Commit history answers the questions you ask most often about a repository: what changed, when, who, and on which branch. On a phone that usually means squinting at a web page. In Gitalchemy, commit history and branch information are ordinary lists, which makes them quicker to read on a small screen than the browser version.

Gitalchemy is a native GitLab client for Android, built with Tauri v2, React and TypeScript and licensed MIT.

Where commit history lives in the app

There are two routes to a commit, and both are worth knowing.

From the project. Open the project and go to its commits. The list is virtualised, so a repository with thousands of commits scrolls without stalling or reflowing the rows under your thumb.

From a merge request. A merge request has a Commits tab next to the diff. That view is narrower and often more useful: it shows the commits the branch actually adds, which is what you want when you are deciding whether to merge it rather than reconstructing what happened to the repository over two years.

Reading a commit list

Each row gives you the essentials: the commit message, the author and the time. That is usually enough to answer "did anything touch this area recently", which is the question that sends most people to the history in the first place.

Where the history on a phone beats the browser is not the data, it is the ergonomics. A native list is fast to scroll, the rows are sized for touch, and you are not fighting a page that reloads and loses your position every time you go back.

The branch matters more than the commits

A commit list only means something once you know which branch it describes, and getting that wrong is one of the easiest mistakes to make on mobile.

Gitalchemy puts the active branch on the project screen, together with the last commit on that branch. So before you read anything, you can see which branch you are on and when it last moved. A branch whose last commit is from two years ago is telling you something before you open a single file.

Switching branches is done from the branch picker, and it reloads the tree and history against the branch you chose. The branches list itself is virtualised, so repositories with hundreds of branches remain workable.

Tags as the released history

Not every interesting point in a repository is a commit. For most projects the useful markers are releases, and those are tags.

The project screen shows a tags count and opens a browsable tags list, so you can see what has shipped and what version you would compare against, without scrolling a commit feed looking for a version bump. If you are trying to work out what changed between two releases, start from tags rather than from a commit list.

Repository browsing alongside the history

Commit history is one view of a repository, and it sits next to the others:

• The repository tree, with a Find file filter, for getting to a file rather than to a change.
• The README, rendered below the code card on the project screen, for what the project says about itself.
• A browsable tags list, for the released history.
• The active branch and its last commit, so you always know what you are looking at.

The repository browsing guide covers those in more detail.

Following a commit into review

Reading history is the start of a task, not the end. The commit you are looking at usually belongs to a merge request, and that is where the app's other half lives: a diff viewer, comments on individual lines, a Start review flow that holds your draft comments until you submit them, and a merge readiness panel with approve, rebase and merge. The merge request review guide walks through it.

Sign-in, if you have not set it up yet

Every screen above needs a connected account. Gitalchemy authenticates with a GitLab personal access token: create one in GitLab under User settings, then Access tokens, choose the scopes you need for the projects you work with, and paste it into the app with your instance URL. Multiple accounts can be connected at once, each with its own cached data, which is what lets you keep a work instance and a personal one apart without signing in and out all day.