In Git, configuration settings are organized into three levels:
local, global, and system.
These levels determine the scope of the configuration, meaning which repositories and users they apply to The order is hierarchical, with local settings taking precedence over global settings, and global settings overriding system settings.
swapn@ASUS MINGW64 ~/OneDrive/Desktop/gitrepos/firstgitrepo (master)
$ git config --global user.name "swapnil vyawhare"
swapn@ASUS MINGW64 ~/OneDrive/Desktop/gitrepos/firstgitrepo (master)
$ git config --global user.email "test@testmail.com"
swapn@ASUS MINGW64 ~/OneDrive/Desktop/gitrepos/firstgitrepo (master)
$ git config --list
Here’s a breakdown of each level:
Local:
Local configurations apply to a single Git repository. These settings are stored in a file named .git/config inside the repository’s directory. Local configurations are useful for project-specific settings, like ignoring certain files or defining custom aliases for frequently used commands.
Global:
Global configurations apply to the current user across all their Git repositories. This is a good place to store user-specific preferences that you want to use consistently, like your name and email address for commits or your preferred text editor for Git commands. Global configurations are stored in a file called .gitconfig in your user’s home directory (e.g., ~/.gitconfig on Unix-based systems).

System:
System-wide configurations are the least common and apply to all users and repositories on the entire system. These settings are typically managed by system administrators and are not recommended for everyday use. They are stored in a file located at /etc/gitconfig (the path may vary depending on your system).
Here’s an analogy to understand the hierarchy: Imagine a company with global policies (global config), individual team preferences (local config), and overall company IT guidelines (system config).Local configs can be more specific than global ones, which in turn can be more specific than system-wide settings.
By understanding these levels, you can effectively customize your Git workflow and manage configurations for different purposes.