Install Git and Configure Identity

A trustworthy Git setup is not “the installer finished.” You need to know which executable your terminal runs, which identity future commits will publish, which configuration scope supplied each value, and which defaults are deliberate rather than copied from an old tutorial.

A reliable setup has four proofs

Before installing: check what already exists

Do not reinstall Git simply because a lesson begins with installation. First ask the current terminal. If git --version reports a Git 2.x release and the executable path is one you understand, you may already have everything this lesson needs.

git --version

# macOS or Linux
command -v git

# Windows PowerShell or Command Prompt
where.exe git

Install Git on Windows

1. 01
   Use Git for Windows

   Download the maintained installer from git-scm.com. It includes Git, Git Bash, OpenSSH, and Git Credential Manager.

2. 02
   Choose the editor deliberately

   The installer may ask for Git’s text editor. Choose one you can actually exit and save from; this can be changed later.

3. 03
   Keep a practical PATH option

   The recommended option that exposes Git to command-line and third-party tools works for most learners.

4. 04
   Open a new terminal

   Verify from PowerShell, Command Prompt, Git Bash, or the editor terminal you intend to use.

Git Bash is optional. It provides a Unix-like shell on Windows, but Git also works in PowerShell and Command Prompt. A shell is the interface; Git is the program.

Install Git on macOS

Run git --version first. macOS may offer Apple Command Line Tools when Git is missing. Accepting that prompt provides a working Git installation. If you already use Homebrew and need its release cadence, brew install git is another reasonable path.

# Apple Command Line Tools
xcode-select --install

# Or, when Homebrew is already your package manager
brew install git

git --version
command -v git

Install Git on Linux

Use your distribution’s normal package manager. This integrates Git with trusted repositories, signatures, dependency handling, and system updates. Compiling Git from source is unnecessary for a normal learning workstation.

# Debian or Ubuntu
sudo apt update && sudo apt install git

# Fedora
sudo dnf install git

# Arch Linux
sudo pacman -S git

git --version
command -v git

Package freshness differs by distribution. The goal here is a supported Git 2.x release with predictable updates, not the highest version number on the internet.

Verify the terminal you will actually use

Repeat verification inside your editor’s integrated terminal if that is where you will work. A standalone terminal and an editor launched earlier can inherit different PATH values.

Configure the identity future commits will publish

Every commit records author and committer metadata. The name and email become durable project history when the commit is shared. Use values you are willing to publish. They do not need to match your operating-system account name.

git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git config --global init.defaultBranch main

Replace the examples; do not type Your Name or you@example.com literally. Quotes preserve spaces in a name. The --global scope writes defaults for repositories used by the current operating-system account.

Choose an email with privacy and attribution in mind

If commits will be public, a personal email inside commit history may be copied indefinitely. GitHub can provide an account-specific no-reply commit address. Copy the exact address shown in GitHub email settings if you want account attribution without publishing your personal address.

Understand configuration scopes and precedence

Git combines settings from several levels. System applies machine-wide. Global applies to the current user. Local lives in one repository and overrides matching broader values there. Command-specific options can be more specific still.

system  /etc/gitconfig              core.autocrlf=input
global  ~/.gitconfig                user.name=Ada Lovelace
global  ~/.gitconfig                user.email=ada@example.com
global  ~/.gitconfig                init.defaultbranch=main
local   .git/config                 user.email=ada@company.example

In the example, commits in that repository use ada@company.example, while other repositories use ada@example.com. The local value wins because it is more specific—not because it was written more recently.

Choose a default initial branch name

init.defaultBranch main tells future git init operations which initial branch name to use. It improves consistency with many current hosts and tutorials. A team may use another convention; project policy wins over personal preference.

The setting does not rename existing branches, change a cloned repository, or create any repository now. It only supplies a default when you initialize one later.

Audit the effective configuration

git config --get user.name
git config --get user.email
git config --get init.defaultBranch

# See effective values, their scope, and the file that supplied each one
git config --list --show-origin --show-scope

The three --get commands answer “what value will Git use?” The final command answers “where did every value come from?” That second question is essential when a local override, old dotfile, managed policy, or second installation creates surprising behavior.

1. VALUE
   Read one effective setting

   Use git config --get user.email when you need a precise answer without a large list.

2. SCOPE
   Identify its level

   --show-scope distinguishes system, global, local, worktree, and command sources.

3. ORIGIN
   Identify its file

   --show-origin shows which configuration file supplied the entry.

4. INTENT
   Keep only deliberate values

   Do not change unrelated settings merely because an old setup checklist mentioned them.

Avoid cargo-cult configuration

Older setup lists often include dozens of commands for line endings, pull behavior, credential storage, aliases, colors, and editors. Each setting encodes a policy. Set it only when you understand the problem it solves.

Troubleshoot from evidence

If two terminals run different Git versions, compare their executable paths and environment. Reinstalling repeatedly can make this worse by adding more candidates without clarifying which one wins.

Independent lab: produce a setup report

On your own machine, install Git only if verification shows it is missing. Then configure deliberate global values and create a short report containing:

• The output of git --version.
• The executable path from command -v git or where.exe git.
• Your chosen author name.
• Whether you used a public, work, or account-specific no-reply email—do not paste a private address into a shared report.
• The effective initial branch default.
• The origin and scope files that supplied those three settings.

Lesson review

A reliable Git setup has evidence. Install from a trustworthy source, verify both version and path, configure a deliberate public commit identity, choose a default initial branch, and inspect configuration with scope and origin. Keep authorship separate from authentication, and avoid settings whose policy you cannot explain.

• I can verify both the Git version and executable path in my real working terminal.
• I understand that commit identity is public metadata, not GitHub authentication.
• I can choose global or local scope based on the intended reach of a setting.
• I know what init.defaultBranch changes and what it does not change.
• I can trace an effective setting to its scope and origin before modifying it.

For platform-specific authentication and GitHub connection steps beyond this lesson’s scope, use the complete Git and GitHub setup guide.