Installing and Verifying Git

Installing Git is more than making a terminal window appear. A reliable setup means knowing which components were installed, proving that the Git executable runs, and confirming exactly which copy the shell selected.

1. What Git for Windows installs

Git for Windows is a distribution containing several related components:

• The Git executable that implements commands such as status and commit.
• Git Bash, which provides Bash and Unix-like command-line tools on Windows.
• Git GUI, a basic graphical interface.
• OpenSSH for SSH connections to repository hosts.
• Git Credential Manager for authenticated HTTPS access.

Git Bash is not Git itself. Opening Git Bash proves that the Bash environment starts, but the Git executable must still be verified separately.

2. Verify that Git runs

Run this in Git Bash, PowerShell, or CMD:

git --version

A successful response looks like:

git version 2.55.0.windows.2

This proves that the current shell found and executed Git. It does not prove which installation was selected when several copies exist.

3. Verify the executable location

In Git Bash:

which git
type -a git

which git reports the first executable Bash will use. type -a git reports every matching command resolution visible to Bash. Example output:

/mingw64/bin/git
git is /mingw64/bin/git
git is /cmd/git

In CMD use:

where git

In PowerShell, use an explicit executable name or PowerShell’s command lookup:

where.exe git
Get-Command git

The shell searches directories in PATH order. The first suitable match is normally selected. If PATH changes, open a new terminal before verifying it again because an existing shell can retain its old environment and command lookup cache.

4. Choosing PATH access during installation

A practical Git for Windows installation normally makes Git available to Git Bash and to Windows command-line tools. This lets PowerShell, CMD, VS Code, and development tools find the same executable.

If Git works in Git Bash but not in PowerShell, Git may still be healthy. Git Bash can configure its own environment while the Windows PATH visible to PowerShell does not contain Git’s command directory.

Do not remove an existing installation merely to change priority. First find all copies, run the intended executable by its full path, and only then adjust PATH. Verify the result in a new terminal.

5. Credential Manager

Git Credential Manager supports authentication when Git connects to remotes over HTTPS. It can guide browser sign-in and store credentials in Windows’ secure credential storage.

It is not needed for local operations such as:

git init
git add .
git commit

Never place an access token in a committed file or embed it permanently in a remote URL.

6. Line-ending choice

Text files contain invisible end-of-line bytes:

Windows       → CRLF
Linux/macOS   → LF

Changing only the line endings still changes file content from Git’s point of view. A whole-file conversion can therefore create a noisy diff even when no visible words changed.

Git for Windows may configure core.autocrlf during installation. Inspect the effective value and its source with:

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

Example:

file:C:/Program Files/Git/etc/gitconfig true

Here, --show-origin means “show the configuration source”; it has nothing to do with a remote named origin. A repository-owned .gitattributes file is a more consistent way for a team to share a line-ending policy. Line endings are covered in depth later in the course.

7. Updating safely

• Obtain updates from the official Git for Windows source, not an unknown download website.
• Record the current version and executable location before updating.
• Close old Git terminals before or after installation as requested.
• Open a new terminal after the update.
• Re-run git --version, which git, and type -a git.
• Confirm that both the version and selected executable location are expected.

Updating the program should not rewrite repository history, but an untrusted installer can execute malicious code. The source of the installer matters as much as its displayed version number.

8. Verification checklist

git --version
which git
type -a git
git config --show-origin --get core.autocrlf

These commands are read-only. They can safely be run inside a repository, but exercises that modify files or history should use a disposable training repository.

9. Common mistakes

• Treating a working Git Bash window as complete proof that Git works.
• Checking the version but not the executable location.
• Assuming the newest-looking installer is safe regardless of its source.
• Confusing --show-origin with a Git remote.
• Adding several Git installations to PATH without checking their order.
• Letting every developer choose unrelated line-ending behavior without a repository policy.

10. Summary

Git for Windows = a distribution containing Git and supporting tools
git --version   = verifies that Git can run and reports its version
which/type -a   = shows which executable Bash resolves
PATH            = controls executable search order
Credential Manager = helps authenticate HTTPS remote operations
.gitattributes  = shares a repository line-ending policy

11. Knowledge check

1. Why is opening Git Bash not enough to verify Git?

It proves that Bash starts, but the Git executable could still be missing, damaged, or resolved from an unexpected location. Run git --version and inspect the executable path.

2. Why check both git –version and which git?

The first reports the version that ran; the second identifies the executable path selected by Bash. Both are needed when several installations may exist.

3. Is Credential Manager required for local commits?

No. Local repository operations need no remote authentication. Credential Manager is used when an HTTPS remote requires identity credentials.

4. Why prefer a repository line-ending policy?

A committed .gitattributes file travels with the repository and gives every developer the same policy instead of relying on unrelated installer choices.