Checkpoint Lab — Installing Git, Configuration Scopes, Identity, Editors, and Credentials

1. Checkpoint scenario — prove configuration precedence without touching your real global config

You will create an isolated “global” config file, point Git at it only for this lab using GIT_CONFIG_GLOBAL, create one disposable repository, apply global defaults plus local overrides, inspect effective origin/scope, observe line-ending/file-mode settings, then remove the environment override and lab directory.

2. Predictions before the first mutation

Write down your answers before running commands:

1. If the isolated global config says user.email=global@example.invalid and the repository-local config later says user.email=repo@example.invalid, which value should a new commit use?
2. Will setting init.defaultBranch=trunk in the isolated global config rename an already-created branch?
3. When GIT_CONFIG_GLOBAL is removed from the environment, should your ordinary global Git configuration become visible again?

3. Setup — Git Bash, Bash, or zsh

mkdir git-config-checkpoint
cd git-config-checkpoint
mkdir isolated-home

export GIT_CONFIG_GLOBAL="$PWD/isolated-home/gitconfig"

mkdir repo
cd repo
git init -b trunk

Keep this terminal open for the lab so the environment variable remains scoped to this shell session.

4. Setup — PowerShell

New-Item -ItemType Directory git-config-checkpoint | Out-Null
Set-Location git-config-checkpoint
New-Item -ItemType Directory isolated-home | Out-Null

$env:GIT_CONFIG_GLOBAL = (Join-Path $PWD 'isolated-home/gitconfig')

New-Item -ItemType Directory repo | Out-Null
Set-Location repo
git init -b trunk

The two setups are equivalent: both redirect only Git's global configuration source for the current process environment.

5. Apply isolated global defaults

git config --global user.name "Global Lab Learner"
git config --global user.email "global@example.invalid"
git config --global init.defaultBranch trunk

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

Expected observation: the three values are reported at global scope, and the origin path points inside git-config-checkpoint/isolated-home/, not your normal home configuration.

6. Apply a repository-local identity override

git config --local user.email "repo@example.invalid"

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

You should see the global name and both email sources when asking for all values. For a normal commit, the higher-precedence local email is selected.

7. Verify the prediction with a commit

Git Bash, Bash, or zsh

printf "checkpoint
" > README.md
git status --short
git add README.md
git diff --staged
git commit -m "Create configuration checkpoint"
git log -1 --format=fuller

PowerShell file-creation alternative

Set-Content README.md 'checkpoint'
git status --short
git add README.md
git diff --staged
git commit -m "Create configuration checkpoint"
git log -1 --format=fuller

Verify: the commit should record repo@example.invalid, proving the local override beat the isolated global email. The global name remains because no local name overrides it.

8. Simulate a project-specific setting

You already satisfied the project-specific identity requirement with a local email. Add one more local setting to make scope visible:

git config --local core.autocrlf false
git config --show-origin --show-scope --get core.autocrlf

This is a lab-specific choice, not a universal recommendation. It demonstrates that repository policy can be narrower than user policy. In a real cross-platform project, shared text rules should normally be expressed with reviewed .gitattributes rather than by asking every developer to copy one global core.autocrlf value.

9. Optional extension — inspect how includeIf would scale project identities

Do not modify your real global config. Inside the checkpoint you can create an extra config file and inspect it directly:

# isolated-home/company.inc
[user]
    email = company@example.invalid

A durable user setup could conditionally include such a file for repositories under a known directory:

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

The checkpoint keeps the actual identity override local because it is easier to make fully portable and fully reversible. Lesson 3 explained the include mechanism and its tradeoffs.

10. Compare line-ending and file-mode observations

git config --show-origin --show-scope --get core.autocrlf
git config --show-origin --show-scope --get core.fileMode || true
git config --show-origin --show-scope --get core.ignoreCase || true
git ls-files --eol

PowerShell users should omit the POSIX || true suffix and run each git config --get separately. A missing value is not necessarily an error in the repository; some settings are omitted or probed differently. core.fileMode and core.ignoreCase can legitimately differ by filesystem.

Optional executable-bit observation on POSIX filesystems

printf '#!/bin/sh
echo hello
' > tool.sh
git add tool.sh
git commit -m "Add test script"
chmod +x tool.sh
git diff --summary

If the filesystem and core.fileMode honor executable changes, the summary may show a mode change. On environments that do not represent the bit the same way, the observation can differ. That difference is the lesson; do not force a machine-specific setting just to make output match a screenshot.

11. Capture the effective-config report

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

Review the report and identify:

• isolated global user.name, user.email, and init.defaultBranch;
• local user.email and core.autocrlf;
• Git-probed local filesystem settings, if present;
• any system-scope settings that remain visible (the lab redirects global config, not system config).

12. Restore the environment before deleting anything

Git Bash, Bash, or zsh

cd ../..
unset GIT_CONFIG_GLOBAL
git config --global --list --show-origin 2>/dev/null || true

PowerShell

Set-Location ../..
Remove-Item Env:GIT_CONFIG_GLOBAL -ErrorAction SilentlyContinue
git config --global --list --show-origin

At this point Git should once again use your normal global configuration sources. Do not compare secret contents; just verify the isolated checkpoint path is no longer acting as global config.

13. Cleanup the disposable checkpoint

Git Bash, Bash, or zsh

pwd
ls git-config-checkpoint
rm -rf git-config-checkpoint

PowerShell

Get-Location
Get-ChildItem git-config-checkpoint
Remove-Item -Recurse -Force git-config-checkpoint

No global restore command is needed because the lab's global config lived inside the disposable directory and the environment override has already been removed.

14. Verification checklist

• The lab repository used an explicit trunk branch.
• GIT_CONFIG_GLOBAL pointed to the disposable checkpoint config while the lab ran.
• The config report showed origin and scope for the relevant values.
• The commit used the repository-local email while retaining the isolated global name.
• No real credentials, tokens, or credential-store contents were printed.
• Line-ending/file-mode behavior was observed rather than forced to match another OS.
• The environment override was removed before the lab directory was deleted.
• Your ordinary global configuration source is active again.

15. Knowledge check

16. What Chapter 02 adds to a production Git operating model

You can now inventory the Git executable, trace every important configuration value to its source, separate commit identity from remote credentials, choose an editor/pager deliberately, respect filesystem-sensitive settings, and design user/repository/automation policy at the correct scope. This is the foundation for reproducible developer environments and CI runners.

17. Chapter checkpoint summary

Predictable Git is not achieved by copying a popular .gitconfig. It comes from observable executable resolution, narrow configuration ownership, explicit identity, safe credential delegation, versioned repository policy where appropriate, and diagnostics that preserve evidence before changing state.

Authoritative references

• git-config
• gitcredentials
• gitattributes
• git-ls-files
• git-var