Installing Git, Configuration Scopes, Identity, Editors, and Credentials: Configuration, Design Choices, and Tradeoffs

1. Configuration is policy encoded at different scopes

Configuration is not a bag of preferences. Some values are personal conveniences, some are repository-specific correctness controls, some belong to automation, and some are filesystem workarounds discovered by Git. The design question is therefore not only “what value do I want?” but also “who should own this value, at what scope, and how will another machine reproduce the intended behavior?”

2. The practical precedence model

Git reads system, global, local, and optionally worktree configuration in order, then accepts environment/command-line overrides. A higher-precedence source can replace a lower-precedence single-valued setting.

git config --list --show-origin --show-scope
# Temporary one-command override:
git -c core.pager=cat log --oneline

Use git -c for an exceptional invocation; use a file scope for durable policy. Do not make a global change merely to fix one repository.

3. user.name and user.email — identity selection

These settings populate author/committer fields of new commits by default. A developer with personal and corporate identities should avoid one global email leaking into every repository. Repository-local values are explicit; conditional includes can scale that pattern across directory groups.

git config --global user.name "Learner Example"
git config --global user.email "personal@example.invalid"

# In a corporate repository:
git config --local user.email "learner@corp.example.invalid"

For stricter multi-identity setups, user.useConfigOnly=true can prevent Git from guessing identity when an explicit configuration is missing.

4. init.defaultBranch — a local creation default, not a universal branch law

git config --global init.defaultBranch trunk

This affects the default branch name for new repositories initialized without an explicit branch argument. It does not rename existing branches, and it does not force a hosting platform to use the same default. Course labs continue to use explicit git init -b trunk so the command is self-describing.

5. core.editor and core.pager — personal workflow choices with automation consequences

An editor is normally interactive, so CI automation should avoid commands that unexpectedly open one. A pager is useful for humans but can complicate captured logs. Prefer explicit non-interactive options in automation:

git commit -m "Automated message"
git --no-pager log -1 --oneline

For humans, configure tools you actually have. For automation, design commands that do not depend on the operator's global editor or pager.

6. credential.helper — delegate secret storage instead of embedding secrets

A credential helper is an external program Git can ask to retrieve/store credentials. Platform credential managers can provide encryption, OS account integration, OAuth flows, or limited in-memory caching depending on the helper.

Never place a token in a remote URL in course examples, a shell history, or repository config. If HTTPS authentication is needed, use the host's documented authentication mechanism and an appropriate helper. SSH authentication follows a different key/agent/host-verification path.

git config --show-origin --show-scope --get-all credential.helper

7. include and includeIf — compose configuration deliberately

Git can include another config file unconditionally or only when a condition matches. A common multi-identity design is to group repositories by directory and conditionally load a corporate identity.

# ~/.gitconfig
[user]
    name = Learner Example
    email = personal@example.invalid

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

# ~/.gitconfig-company
[user]
    email = learner@company.example.invalid

The gitdir: condition matches repository .git locations. Current Git also supports other include conditions such as branch or matching remote configuration. Keep include trees understandable; invisible layering is a common source of “where did this value come from?” incidents.

8. Worktree scope is specialized, not “one more global file”

Linked worktrees share much repository state. Worktree-specific configuration is stored separately only when the repository enables the worktree-config extension. Without that, git config --worktree behaves like local configuration. Do not introduce worktree scope merely because it exists; use it when linked worktrees genuinely need different values.

9. core.autocrlf, core.eol, and project-level line-ending policy

Newline conversion is a boundary between repository content and the checked-out working tree. core.autocrlf=true requests CRLF in the working tree for text while normalizing repository content; input performs input normalization without output conversion. core.eol chooses working-tree EOL for text but is overridden by active core.autocrlf modes.

Do not copy a one-size-fits-all global line-ending recipe. A cross-platform project can declare text/binary/EOL intent in .gitattributes, version it, review it, and apply it consistently to all clones.

# .gitattributes example
* text=auto
*.sh text eol=lf
*.ps1 text eol=crlf
*.png binary

The exact policy must match the project's tooling. For example, many PowerShell projects work perfectly with LF; the example demonstrates mechanism, not a universal recommendation.

10. core.fileMode — honor what the filesystem can represent

Git tracks an executable bit for files. git init and git clone normally probe the filesystem and set core.fileMode accordingly. Network mounts, Windows interoperability layers, or copied repositories can change filesystem behavior after initialization. Diagnose before changing this setting.

git config --show-origin --get core.fileMode
git diff --summary

11. core.ignoreCase — a filesystem workaround, not a naming policy

On a case-insensitive filesystem Git may set core.ignoreCase=true. Current documentation warns that changing the probed value can cause unexpected behavior. The project-level solution is to avoid paths that differ only by case when collaborators use mixed filesystems.

12. Decision table — where should this choice live?

13. Worked scenario — laptop, corporate repos, and CI

A developer wants nano as a personal editor, uses a personal email for hobby projects, a corporate email for repositories under ~/work/company/, and runs CI in a container.

1. Put the editor and personal identity in global config.
2. Use includeIf gitdir: to load the corporate email only for the company directory.
3. Put shared text/EOL rules in the repository's .gitattributes.
4. In CI, set the exact automation identity only when CI creates commits, avoid interactive editor/pager flows, and inject authentication through the platform's secret mechanism rather than inheriting a developer credential helper.

This design separates personal preference, repository policy, and automation secrets.

14. Knowledge check

15. Summary

Good Git configuration design assigns each setting to the narrowest owner that actually needs it. Personal UI preferences can be global; project correctness belongs in versioned policy where possible; repository identity may be local/conditional; filesystem probes should be respected; secrets belong in credential/security systems, not config text.

Authoritative references

• git-config
• gitcredentials
• gitattributes
• git-worktree