Defaults

Git has useful defaults that affect how new repositories and common commands behave. Each setting solves a different problem, so inspect the existing value and understand its scope before changing it.

1. The initial branch name

The following setting chooses the initial branch name for repositories created later with git init:

git config --global init.defaultBranch main

It does not rename branches in existing repositories. An explicit option can override the default for one new repository:

git init --initial-branch=release
git init -b release

The global value remains unchanged after that one-time override.

Inspect the configured default:

git config --get --show-scope --show-origin init.defaultBranch

2. Git’s text editor

Some commands need text that is longer than a command-line option. Git opens a configured editor and reads the saved temporary file after editing finishes.

For Visual Studio Code:

git config --global core.editor "code --wait"

The full stored value is:

code --wait

code opens Visual Studio Code. --wait keeps the editor command running until the temporary file is closed. Without it, Git may read the file before a message has been written.

Other command-line editors can be configured when they are installed and available through PATH:

git config --global core.editor "notepad"
git config --global core.editor "vim"
git config --global core.editor "nano"

This setting controls the editor Git launches for requested text. It does not choose the editor used for ordinary project files.

3. Why line endings need a policy

Operating systems commonly represent the end of a text line differently:

Windows       → CRLF
Linux / macOS → LF

The visible words can be identical while the stored bytes differ:

Hello<LF>
Hello<CR><LF>

In Git Bash, this command can reveal the extra carriage-return character:

cat -v file.txt

Output such as Hello^M usually indicates CRLF; ^M represents the CR part, while the line break represents LF.

4. Line-ending conversion

The setting controls conversion while content moves between the working tree and Git’s stored form:

git add / input     → Working Tree to Git storage
checkout / output  → Git storage to Working Tree

With this value:

core.autocrlf = true

the simplified behavior is:

Input  → CRLF becomes LF
Output → LF becomes CRLF

This is common in Git for Windows installations. The repository can keep LF while the Windows working tree uses CRLF.

With this value:

core.autocrlf = input

the simplified behavior is:

Input  → CRLF becomes LF
Output → no conversion

This is commonly useful on systems whose working files use LF.

With this value:

core.autocrlf = false

this setting performs no automatic conversion in either direction. A CRLF file can therefore remain CRLF when staged unless a repository policy says otherwise.

Inspect the actual value instead of assuming it from the operating system:

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

A committed .gitattributes file is the better place for a shared repository policy because every developer receives it. Its syntax and full behavior are covered later in the course.

5. How line-ending problems appear

Different working-tree forms are normally safe when every developer stores the same normalized content:

Repository             = LF
Windows working tree   = CRLF
Linux working tree     = LF

Problems arise when inconsistent settings cause developers to commit different line-ending forms. A file can then appear completely changed even when its words are mostly unchanged. That creates noisy reviews and can contribute to a conflict when another change overlaps the affected lines.

A warning about replacing line endings describes conversion; it is not by itself a merge conflict.

6. Pull policy signposts

These settings choose default integration constraints for git pull:

pull.rebase
pull.ff

Do not choose values blindly. Their effects depend on merge, rebase, fast-forward history, and remotes. Those concepts have dedicated checkpoints later in the course. At this stage, know that the settings exist and that a team should choose them only after understanding those workflows.

7. Pruning signpost

This setting can remove stale local references that represent remote branches which no longer exist on the hosting service:

git config --global fetch.prune true

It does not delete ordinary local branches or working files. Fetch behavior and remote-tracking references are covered in their dedicated checkpoint.

8. Simple aliases

An alias gives a short name to a Git command:

git config --global alias.st status

Use it through Git:

git st

This runs:

git status

An alias defined by Git is not an independent shell command. Running st alone will not work unless the shell has a separate alias with that name.

Start with simple, transparent aliases. Too many aliases can hide the original commands, make instructions difficult to share, and create dependencies on one machine’s personal configuration.

9. Inspect before changing

The same inspection pattern works for every key:

git config --get --show-scope --show-origin <key>

No output with exit status 1 normally means the key is not configured in the requested context. It does not mean that an empty value is stored.

10. Common mistakes

• Expecting init.defaultBranch to rename existing branches.
• Configuring core.editor as code without waiting for editing to finish.
• Assuming an operating system guarantees a particular core.autocrlf value.
• Treating false as normalization instead of no conversion by that setting.
• Confusing a line-ending conversion warning with a merge conflict.
• Choosing pull settings before understanding the workflows they control.
• Believing fetch.prune deletes ordinary local branches.
• Running a Git alias without the git prefix.

11. Summary

init.defaultBranch = initial name for future repositories
core.editor        = editor Git launches when it needs text
core.autocrlf      = line-ending conversion between storage and working tree
pull.*             = future integration-policy settings
fetch.prune        = cleanup of stale remote references
alias.<name>       = personal shorthand for a Git command

12. Knowledge check

1. Does changing init.defaultBranch rename an existing branch?

No. It supplies the initial name for repositories created afterward.

2. Why does the VS Code editor command include –wait?

It prevents Git from reading the temporary file before editing has finished.

3. With core.autocrlf=true, what happens on input and output?

Input converts CRLF to LF. Output converts LF to CRLF in the working tree.

4. Does fetch.prune=true delete an ordinary local branch?

No. It cleans stale references representing deleted remote branches.

5. How is a Git alias invoked?

With the git prefix, such as git st, unless an unrelated shell alias also exists.