Introduction

Git can color most of its command output, but the final result depends on both Git settings and the terminal that renders the ANSI escape codes. If color still looks wrong after configuration, the terminal theme or pager is often the missing piece.

Start With color.ui

The core switch is color.ui. For most setups, auto is the right value:

git config --global color.ui auto

auto tells Git to color output when writing to an interactive terminal and to avoid raw escape sequences when output is redirected to a file or another command that may not handle them well.

You can inspect the current setting with:

git config --global --get color.ui

Possible values are:

• 'auto'
• 'always'
• 'never'

always is occasionally useful for a one-off command, but it is usually a bad global default because redirected output will include visible escape codes.

Customize Specific Sections

Git lets you set colors for status output, diffs, branches, and more. Some useful examples are:

1git config --global color.status.added green
2git config --global color.status.changed yellow
3git config --global color.status.untracked red
4git config --global color.branch.current "yellow reverse"
5git config --global color.diff.old "red bold"
6git config --global color.diff.new "green bold"

These settings control the appearance of commands such as git status, git branch, and git diff.

If you prefer editing the config file directly, the same configuration can live in ~/.gitconfig:

1[color]
2    ui = auto
3[color "status"]
4    added = green
5    changed = yellow
6    untracked = red
7[color "branch"]
8    current = yellow reverse
9[color "diff"]
10    old = red bold
11    new = green bold

Direct file editing is often easier when you want to copy the same theme between machines.

Understand Git's Color Syntax

Git colors are built from a color name plus optional attributes. Common color names include:

• 'red'
• 'green'
• 'yellow'
• 'blue'
• 'magenta'
• 'cyan'
• 'white'
• 'black'

Common attributes include:

• 'bold'
• 'dim'
• 'ul'
• 'reverse'

So a value such as "blue bold" or "yellow reverse" is valid. The exact appearance depends on your terminal palette, which means the same Git config can look very different across terminals.

Paging Colored Output Correctly

A common complaint is that color disappears when output goes through a pager. The usual fix is to preserve ANSI codes:

git -c color.ui=always diff | less -R

less -R allows raw color escape sequences to render correctly. Without that, piping output may strip or mis-handle colors.

If you want a pager configured permanently, you can set:

git config --global core.pager "less -FRX"

That helps long diffs remain readable while still behaving well in the terminal.

The Terminal Theme Still Matters

Git only emits color instructions. Your terminal decides what "red" or "bold green" actually looks like. If git diff uses colors that are hard to distinguish, the problem may be low contrast in the terminal theme rather than a Git configuration bug.

This is especially noticeable in default light themes or terminals with muted palette values. Changing the theme can be more effective than endlessly tweaking Git color names.

Test With Real Commands

After changing the configuration, test it with commands that exercise the configured sections:

1git status
2git diff
3git branch
4git log --oneline --decorate

If one command still looks plain while another is colored, the problem may be the specific section you did or did not configure.

Going Beyond Built-In Git Coloring

If you want richer diff rendering, many developers install a pager such as delta. Git can hand its diff output to that tool:

git config --global core.pager delta

That is not required for ordinary Git colorization, but it is a useful upgrade if you spend a lot of time reviewing diffs in the terminal.

Common Pitfalls

The most common mistake is setting color.ui=always globally and then being surprised when copied output or redirected logs contain unreadable escape sequences. auto is safer.

Another mistake is changing Git config but testing inside a tool that strips ANSI output, such as a limited terminal emulator or a pager not configured to pass color through.

Developers also often over-customize. If added, changed, and untracked entries all use similar shades, the configuration may look flashy but communicate less information.

Finally, remember that Git and the terminal share responsibility. A perfect .gitconfig can still look poor under a weak terminal theme.

Summary

• Enable color with git config --global color.ui auto.
• Customize sections such as status, diff, and branch to match your workflow.
• Use less -R when paging colored output through less.
• Check the terminal theme if Git colors are technically enabled but hard to read.
• Use a richer pager such as delta only if you want more than Git's built-in ANSI coloring.