Colours and symbols
The mark on a changed file, the colour it is drawn in, and the second mark that says what the next commit will contain.
A changed file in the working copy carries two marks, and they answer two different questions. At the left, what happened to the file. At the right, whether it is going into the next commit. The first of them turns up wherever Innesta lists a changed file, so it is worth learning once.
What happened to the file
In the working copy, and in a stash, the mark is a letter in a tile. In a commit’s files, and in the preview an operation shows before it runs, it is a symbol. The states are the same, and so are the colours.
| In a file list | As a symbol | Means | Colour |
|---|---|---|---|
A | a circled plus | Added | green |
? | a circled question mark | Untracked | green |
C | two pages | Copied | green |
M | a page of text | Modified | amber |
R | two arrows round a circle | Renamed | amber |
D | a circled minus | Deleted | red |
! | a warning triangle | Conflict | red |
Grey is the fallback. A file Innesta can say nothing more about than that it changed — a binary one, for instance — is drawn in grey rather than given a colour it has not earned.
Why those three colours
They are chosen for what the change does to the file, not for the letter Git prints:
- Green is content that was not there before — an addition, a copy, a file Git has never seen.
- Amber is content that was there and is no longer as it was — an edit, a rename.
- Red is content that has gone, or that Git could not settle on its own — a deletion, a conflict.
One mapping serves the whole app: a modification is the same amber in the working copy, in a commit, and in the preview an operation shows before it runs. And the same three colours report how anything else stands, so the reading carries — green is new or settled, amber wants looking at, red wants a decision. Blue is deliberately not in the set: it belongs to the remote — what has been fetched, what is waiting to go — and never describes a change of yours.
Colour is never the only signal. Every mark above is a letter or a symbol before it is a colour, and the state has a name too: printed beside the file in an operation preview, under the pointer in the working copy, and read out by VoiceOver everywhere. Nothing in a file list is told apart by hue alone.
What the next commit will contain
At the other end of a working copy row is a second mark, and it says one thing only: how much of that file is staged.
| Mark | Means |
|---|---|
| a hollow circle, grey | Unstaged — none of it is in the next commit |
| a half-filled circle, amber | Partially staged — staged, then edited again |
| a filled tick, green | Staged — all of it is in the next commit |
Point at the row and that mark becomes the action it offers: a green plus to stage, an amber minus to unstage. Staging changes is what to do with it.
The two columns are independent, and that is why there are two of them: a file
is Modified and Staged, not one or the other. The single case
where staging changes the left-hand mark is an untracked file, whose ? becomes
an A — Git has recorded it for the first time, which is a change in what
happened to the file rather than in what the commit will contain.
A file with an unresolved conflict reads as Unstaged whatever Git’s index says about it, because until you have resolved it there is nothing there worth committing.
A list you cannot stage from — a stash, or a commit you are only reading — draws no second mark at all.