Git configuration can come from several places. A setting may be defined for every user on a machine, for one user, for one repository or, when enabled, for an individual Git worktree.

You rarely need to hunt through the filesystem manually. Modern Git can tell you which configuration files it is reading and exactly where each setting originated.

The most useful diagnostic command is:

git config --list --show-origin --show-scope

This displays each setting together with its scope and source file.

Git configuration scopes and precedence

For the configuration files developers encounter most often, Git applies settings from broader scopes first and lets more specific scopes override them.

Scope Typical purpose Precedence
SystemSettings for users on the machineLowest of these four
GlobalSettings for the current userOverrides system
LocalSettings for the current repositoryOverrides global
WorktreeSettings for a specific worktree when enabledOverrides local

For example, if user.email is defined globally and again locally, the repository's local value wins while you work in that repository.

Git also has command, environment and conditional configuration mechanisms, so the complete configuration system is more flexible than these four files alone. For everyday repository administration, however, system, global, local and worktree scopes are the important starting point.

Where is the global Git config file?

The traditional per-user global configuration file is:

~/.gitconfig

On Windows, that normally resolves to a path such as:

C:\Users\username\.gitconfig

On Linux, it normally resolves to:

/home/username/.gitconfig

Git also supports an XDG global configuration file:

$XDG_CONFIG_HOME/git/config

If XDG_CONFIG_HOME is not set, the conventional location is:

~/.config/git/config

Because more than one global path is possible, asking Git where a value came from is more reliable than assuming ~/.gitconfig is always the only global file.

Windows Git config file locations

Scope Typical Windows location
System<Git-installation>\etc\gitconfig
GlobalC:\Users\username\.gitconfig or the XDG global config
Local<repository>\.git\config
Worktree<git-dir>\config.worktree when worktree configuration is enabled

Git for Windows can also use a system-wide configuration associated with its installation and Windows-specific configuration locations. Installation details can therefore affect the exact system path.

Instead of guessing, use Git itself:

git config --system --list --show-origin
git config --global --list --show-origin
git config --local --list --show-origin

Linux Git config file locations

Typical Linux locations are:

Scope Typical Linux location
System/etc/gitconfig
Global~/.gitconfig and/or ~/.config/git/config
Local<repository>/.git/config
Worktree<git-dir>/config.worktree when enabled

One important correction to older examples is that the Linux system path is /etc/gitconfig, not ~etc/gitconfig. The tilde represents a user's home directory and does not belong in the system path.

Find every Git config file Git actually reads

To see the configuration Git resolves for the current repository, including the source of each setting, run:

git config --list --show-origin --show-scope

Output will resemble:

system  file:/etc/gitconfig              core.autocrlf=input
global  file:/home/cameron/.gitconfig    user.name=Cameron
global  file:/home/cameron/.gitconfig    user.email=user@example.com
local   file:.git/config                  user.email=repo@example.com

The local user.email wins because local configuration is more specific than global configuration.

Find where one Git setting came from

If you only care about one property, ask Git for that property and include its origin and scope:

git config --show-origin --show-scope --get user.email

You can also query a specific scope:

git config --system --get user.email
git config --global --get user.email
git config --local --get user.email

This is much easier than opening several configuration files and manually determining which value takes precedence.

Set Git configuration values

Most developers configure their identity globally:

git config --global user.name "Cameron McKenzie"
git config --global user.email "user@example.com"

A repository can override those values locally:

git config --local user.email "work@example.com"

You can then verify the effective value:

git config --show-origin --show-scope --get user.email

Edit Git configuration files safely

Git can open the appropriate configuration file in your configured editor:

git config --global --edit
git config --local --edit
git config --system --edit

Editing the system configuration may require administrator or root privileges. Avoid using sudo with --global unless you intentionally want to modify the root user's global configuration rather than your own.

On Linux, for example:

sudo git config --system --edit

is reasonable when system-level configuration requires elevated permissions, while:

git config --global --edit

should normally run as your regular user.

What if .gitconfig does not exist?

Do not assume something is wrong simply because ~/.gitconfig does not exist. Git does not require every possible configuration file to be present.

Creating a global setting will create or update the appropriate global configuration:

git config --global user.name "Cameron McKenzie"
git config --global user.email "user@example.com"

You can then inspect its origin with:

git config --global --list --show-origin

How Git worktree configuration works

Repositories that use multiple worktrees can enable worktree-specific configuration:

git config extensions.worktreeConfig true

After that feature is enabled, settings can be written with the --worktree scope:

git config --worktree user.email "worktree@example.com"

Worktree-specific configuration is stored separately from the repository's shared local configuration, which allows individual worktrees to override selected settings.

Use conditional includes for multiple identities

Developers who use different identities for work and personal repositories do not need to repeatedly change user.email. Git supports conditional configuration includes.

For example, a global configuration can load another file for repositories stored under a work directory:

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

The referenced file can contain the work-specific identity:

[user]
    name = Cameron McKenzie
    email = work@example.com

This is cleaner and less error-prone than manually changing your global identity whenever you move between personal and corporate repositories.

Git config location command reference

Task Command
Show all effective settings, scopes and source filesgit config --list --show-origin --show-scope
Show one setting and its sourcegit config --show-origin --show-scope --get user.email
List global settingsgit config --global --list --show-origin
List local settingsgit config --local --list --show-origin
Edit global configgit config --global --edit
Edit local configgit config --local --edit
Set global usernamegit config --global user.name "Your Name"
Set repository-specific emailgit config --local user.email "you@example.com"

The key lesson is that you usually do not need to memorize every Git configuration path. Use --show-origin and --show-scope to let Git identify the active configuration files and explain exactly where each setting came from.