Installing Git, Configuration Scopes, Identity, Editors, and Credentials: Concepts, Architecture, and Mental Model

1. The problem — the same repository can behave differently on two machines

Chapter 01 established that a Git repository owns its local history and exchanges changes explicitly. That model is incomplete until you know which Git program is running and which configuration it is reading. A developer laptop, CI runner, container, and build agent can open the same repository but choose different editors, identities, credential helpers, line-ending behavior, or filesystem workarounds.

Configuration drift is therefore not cosmetic. It can change commit metadata, default branch creation, authentication behavior, visible diffs, executable-bit tracking, and whether a command appears to “hang” while an editor or pager is waiting.

2. Separate the layers before troubleshooting

Four things that beginners often call “Git” are actually different layers:

• Git executable: the installed program that implements Git commands.
• Terminal and shell: the program/environment that parses your command line and starts git. Git Bash, Bash, zsh, PowerShell, Command Prompt, and terminal applications are not Git itself.
• Repository: the local object/ref/config state, normally rooted at a .git directory for a non-bare repository.
• Hosting service: GitHub, GitLab, Bitbucket, Azure Repos, or another server. These products can host Git repositories and add review/permission features, but they are not the local Git executable.

3. Mental model — command, configuration, repository, and remote

flowchart LR
S[Terminal / shell] --> G[Git executable]
C1[System config] --> G
C2[Global config] --> G
C3[Local repository config] --> G
C4[Worktree config when enabled] --> G
E[Environment + git -c overrides] --> G
G --> R[Local repository state]
G -. only when command needs it .-> H[Remote / hosting service]
G -. may launch .-> X[Editor / pager / credential helper]

The solid arrows describe local inputs to the Git process. The dotted arrows are conditional: git status does not need GitHub, but git fetch may contact a remote; a commit without -m may launch an editor; a long log may launch a pager; HTTPS authentication may invoke a credential helper.

4. Configuration scopes and precedence

Git reads configuration from multiple scopes. System configuration is machine-wide. Global configuration belongs to a user. Local configuration belongs to one repository. Worktree configuration can be separate per linked worktree when that feature is enabled. Command-scope values such as git -c name=value … are temporary for one invocation.

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

This is one of the most valuable read-only diagnostic commands in the course. It does not merely print a value; it tells you where the value came from and its scope. When a single-valued setting appears at several scopes, later/higher-precedence sources usually determine the effective value. Multi-valued settings require more care because multiple values may intentionally accumulate.

5. Identity is commit metadata; credentials authenticate transport

user.name and user.email normally populate the author and committer fields of new commit objects. They answer “what identity should this commit record?” They do not prove that you are allowed to push to a server.

Credentials answer a different question: “can this process authenticate to the remote service?” An HTTPS token, SSH key, OAuth session, or credential-manager entry may authenticate transport. Changing user.email does not log you into GitHub, and logging into a host does not automatically choose the correct commit email.

6. Editors, pagers, and credential helpers are child tools

Git sometimes launches other programs. An editor collects a commit/tag message. A pager keeps long output readable. A credential helper obtains or stores authentication material. Git configuration selects these tools, but they run as separate processes with their own platform behavior.

git var GIT_EDITOR
git var GIT_PAGER
git config --show-origin --show-scope --get-all credential.helper

If the last command prints nothing and exits non-zero, that can simply mean no helper is configured in the files Git read. It does not mean “no credentials exist anywhere,” and you should never dump credential stores merely to investigate a prompt.

7. Filesystem behavior becomes Git behavior at the working-tree boundary

Git stores file content and modes in its repository model, but checkouts live on real filesystems. Windows, Linux, and macOS environments can differ in case sensitivity, executable-bit support, newline conventions, symlink behavior, and path syntax.

• core.fileMode tells Git whether to honor executable-bit changes in the working tree. Git normally probes this when a repository is initialized or cloned.
• core.ignoreCase enables workarounds when the filesystem is not case-sensitive. Git also probes this; changing it casually can create surprising behavior.
• core.eol and core.autocrlf affect working-tree newline conversion for text. Repository-level .gitattributes is usually a better place for shared project policy than assuming every developer should copy the same global setting.

8. Read-only inspection before configuration changes

Run these before changing anything on a workstation or CI image:

git --version
git --exec-path
git config --list --show-origin --show-scope
git config --show-origin --show-scope --get-regexp '^(user|core|credential|init)\.'

The regular-expression query may return no match for some categories. That is useful evidence: absence is different from an inherited value whose origin you did not expect.

9. Why this matters in DevOps

A pipeline should not depend on a developer's hidden global editor, credential helper, branch default, or newline conversion. Build agents should either declare the configuration they rely on or prove the inherited environment is acceptable. Reproducible delivery begins by making these inputs observable.

10. Micro-lab — inventory your Git environment without changing it

Use any repository, including the Chapter 01 disposable lab if you still have it. Do not edit configuration yet.

git --version
git --exec-path
git rev-parse --show-toplevel 2>/dev/null || true
git config --list --show-origin --show-scope

Record the Git version, executable family/location, whether you are inside a repository, and any surprising configuration origins. Do not “fix” a surprising value until you understand which scope owns it.

11. Knowledge check

12. Summary

Git behavior is the product of an executable, layered configuration, repository state, environment, filesystem, and sometimes child tools or a remote service. Troubleshooting becomes far easier when you identify the layer before changing it.

Authoritative references

• git documentation
• git-config
• gitcredentials
• gitattributes