Git Changes

The Git tab of a project has sub-tabs. This page is about two of them:

• Changes: uncommitted changes. Read each diff, select files and commit them.
• History: commits on the current branch, with the diff of each commit.

For Issues and Actions, see GitHub Integration.

The tab is available for all projects. To browse and edit files, use Files.

When a project has changes, the Git tab label shows the number of added and removed lines, for example +12 −3. The projects sidebar shows the same numbers. The Changes sub-tab shows the number of changed files. The numbers update automatically when files in the project change.

Hover over the numbers to see a tooltip with the exact numbers of added and removed lines and the number of changed files. The project cards on the dashboard show the same numbers.

The app keeps the last sub-tab of each project.

The Changes view shows all changes compared to the last commit (HEAD). The list updates automatically while the tab is open and the window has focus, and when you come back to the window. To update it now, click the refresh icon.

The file list

Letter	Meaning
M	Modified
A	Added (staged new file)
U	Untracked (new file that Git does not track yet)
D	Deleted
R	Renamed
C	Copied
T	Type changed (for example, a file became a symbolic link)
!	Merge conflict

Each row shows the number of added (+) and removed (−) lines. A binary file shows bin.

The top bar shows the current branch. If the branch has an upstream, it also shows the number of commits to push (↑) and to pull (↓).

Read the diffs

The right side shows the diffs of all changed files, one after the other. Click a file in the list to go to its diff.

Changed words in a line are highlighted. The app keeps your choice of Unified or Split.

Some diffs are hidden at first to keep the view fast. Click Load diff to show them:

File	Why
Lock files and minified files (for example composer.lock, package-lock.json, *.min.js)	They are generated and usually not reviewed
Very large diffs	They are too large to read quickly
Some new files, when there are many new files	Many new files slow down the view

Binary files have no text diff. A very long diff, or a diff of a file in a less common language, shows without syntax colors.

Select files and commit

Each file has a checkbox. A selected file is staged for the next commit.

• A dash in a checkbox means that only part of the file is staged (for example, you staged some lines in a terminal). Select it to stage the full file.

To commit:

1. Select the files.
2. Type a commit message. The first line is the summary.
3. Click Commit or press ⌘ ↵ (macOS) or Ctrl ↵ (Windows and Linux).

After the commit, a notification shows the commit hash and summary.

The app does not push. Push from the terminal or from your Git tool.

Leave and come back

When you go to a different tab or project, the app keeps for each project:

• The commit message that you typed
• The selected file, and the scroll position of the list and the diffs
• A commit that is in progress, and its error

If a commit fails while you are on a different tab, the error shows when you come back. The error goes away when you select or clear a file, or commit again. After a successful commit, the app clears the message only if you did not change it during the commit.

Commit hooks

Your commit hooks run as they do in a terminal (for example Husky, lint-staged or a pre-commit hook). If a hook stops the commit, its output shows under the message box. Your message and selection stay, so you can fix the problem and commit again.

History

The History view lists the commits on the current branch, newest first.

Each commit shows:

• The summary, the author and the time.
• The short commit hash.
• ↑ if the commit is not pushed to the upstream branch yet.
• The branches and tags that point to it. The current branch is green, tags are blue, and remote branches have a globe icon.

Click a commit to see:

• The full message, the author and the date. If another person committed it, the committer too.
• The parent commit. Click the parent hash to go to it.
• The changed files and their diffs, in Unified or Split view.

For a merge commit, the diff compares the commit to its first parent.

The list updates automatically while the view is open and the window has focus.

The History view is read-only.

Keyboard shortcuts

Click the file list or the commit list first. Then:

Key	Changes	History
J or ↓	Next file	Next (older) commit
K or ↑	Previous file	Previous (newer) commit
Space	Select or clear the current file
S	Change between Unified and Split	Change between Unified and Split

Safety

Opening a project must never run code from that project. When the app reads changes or history, it ignores these settings in .git/config:

• core.fsmonitor commands
• external diff programs and textconv commands
• clean, smudge and process filters
• log.showSignature, so that no signature program runs when the history loads

Settings in your global Git config (for example Git LFS) still apply. When you stage files, the Git LFS filter from the repository config also applies.

The app reads changes without the Git index lock, so it does not block Git commands that you run in a terminal at the same time.

Troubleshooting

Message	What to do
Not a Git repository	Run git init in the terminal.
Git does not trust this folder	Another user owns the folder. If you trust it, click Trust this folder. This adds the folder to safe.directory in your global Git config.
Git is not available	Install Git and make sure it is on your PATH. In WSL mode, install Git in the WSL distribution.
Another Git process is using this repository	Wait for the other Git command to finish, then try again. If no Git command runs, delete .git/index.lock.
Git needs your name and email	Run git config --global user.name "Your Name" and git config --global user.email [email protected].

WSL

In WSL mode, the app runs Git inside your WSL distribution, where the project files are.