Become a Git Super User — Part 2: Installing and Setting Up Git

In the previous articles, we explained what Git is, how it differs from other Version Control Systems and how it tracks file changes. Now it’s time to install Git and use this powerful tool.

By the end of this blog, you should:

1. Install Git on your system
2. Setup the basic Git configuration

Before we start, you can find all the articles in the ‘Become a Git Super User’ series below:

1. Become a Git Super User — Part 0: What is a Version Control System? The introduction
2. Become A Git Super User — Part 1: How does Git Work?
3. Become a Git Super User — Part 2: Installing and Setting Up Git

Let’s get started!

How to install Git?

First, you can check if you already have Git installed or not. To check that, all you need to do is open the terminal and run the command below:

$ git - version

If you have Git installed, you should see something similar to this (your Git version might be different):

git version 2.39.3

If you don’t have Git installed, depending on your OS, there are different ways to install Git

For Linux machines, you can use a package management tool to install. If you’re on Fedora (or any closely related RPM-based distribution, such as RHEL or CentOS), you can use:

$ sudo install git-all

If you’re on a Debian-based distribution, such as Ubuntu, you can use apt and install it by the following command:

$ sudo apt install git

For MacOS, you can either install Git using the brew package manager and install it like below:

$ brew install git

Or you can install Xcode which has Git already installed.

For Windows machines, you can download Git from here or use WinGet to install it using the command below

$ winget install — id Git.Git -e — source winget

Please see documentation for other Git installation options.

How to set up Git after installation?

Now that Git is successfully installed on your system, you can start customising it to your taste. You only need to do these customisations once on any computer as the configurations you make would stay the same between upgrades.

You can view and edit Git configurations using the git config command. It lets you control all aspects of Git by letting you get and set configuration variables. Configuration variables are stored in the three different places on your system. These places are:

• The /etc/gitconfigfile holds system-wide Git configurations, affecting all users and repositories. Changes require admin privileges. You need to pass the — system flag to git config to read and write these settings
• The ~/.gitconfig or ~/.config/git/config file stores user-specific settings, impacting all repositories you work with. You need to pass — global option to edit the global user-specific settings
• config file in the Git directory (.git/config) within a repository contains configurations specific to that repository. git config works with the local settings by default but you can pass the optional — local flag to the Git command to edit the local Git configuration of the repository.

Keep in mind that each level’s configurations override the values of the previous level. For example, the values you set using the — local flag to customise the Git environment of the current repository overrides the values of the previous level ( — global & — system ).

On Windows, Git primarily searches for the user-specific .gitconfig file within the user’s home directory (typically C:\Users$USER). It also looks for a system-wide configuration file, but its location varies:

• Older Git versions: [path]/etc/gitconfig relative to the MSys root (wherever Git was installed).
• Git for Windows 2.x or later:
• C:\Documents and Settings\All Users\Application Data\Git\config on Windows XP.
• C:\ProgramData\Git\config on Windows Vista and newer.
• Only an administrator using git config -f <file> can modify this file.

The image below summarises the locations of Git configuration files on Windows and Linux systems

Figure 1. Git Configuration Files on WIndows and Linux. [source]

There is also a Worktree configuration which is more specific that Local configs you set. We cover this configuration when we get to talk about branching in Git but you can find more info about it here.

Set Identity Configuration

One of the first things you need to do after installing Git is to set your username and email address. Every commit in Git uses this information and as soon as you start committing changes, your Git identity information is stored with them. To set up your username and email, use the commands below

$ git config — global user.email “YOUR EMAIL ADDRESS”

You only need to do this once if you use the — global flag as the information will be stored for all your Git repositories. If you want to set these configs for the project you’re working on, you can emit the — global flag as Git updates the local settings by default.

Configuring Your Default Text Editor

Git allows you to personalise your workflow by setting your preferred text editor for editing commit messages and other text-based interactions. If you haven’t configured one, Git defaults to your system’s default editor.

If you’d rather use an alternative editor like Emacs, (or, you know, avoid the eternal struggle of exiting Vim), you can easily configure it globally:

$ git config — global core.editor emacs

On Windows, you must provide the full path to your editor’s executable file. This path might vary based on how your editor was installed. For example, to set the default editor to notepad++, you can do it like this:

$ git config — global core.editor “‘C:/Program Files (x86)/Notepad++/notepad++.exe’

Customising Git Default Branch Name

We haven’t talked about the concept of branching in Git yet, but here’s a quick tip you can use to customise your Git experience.

Your default branch name

When you create a new Git repository, it automatically starts with a branch named “master”. However, you have the option to change this default branch name to something else, like “main”.

How to change it

If you prefer to use “main” as your default branch name, you can do so with this command:

$ git config — global init.defaultBranch main

This tells Git to use “main” instead of “master” whenever you create a new repository.

Remember:

• We’ll explore branching in more detail later, but for now, just know that this command lets you personalise your Git setup a bit.
• If you’re working with existing repositories that already use “master”, don’t worry! We’ll cover how to handle that when we learn about branching.

Checking Your Git Configuration

You can easily review your Git configuration settings using the git config — list command. This will display all the settings Git can currently find, potentially including duplicates if the same key is defined in multiple files (e.g., both system-wide and user-specific configurations). Git prioritises the last value it encounters for each unique key.

To check the specific value Git associates with a particular key, use git config <key>.

Understanding Configuration Conflicts

Since Git might source the same configuration variable from multiple files, you might encounter unexpected values. In such cases, the git config — show-origin <key> command reveals which configuration file ultimately determined the value for that key. An example can be found below

$ git config — list
user.name=John Doe
user.email=johndoe@example.com
color.status=auto
color.branch=auto
color.interactive=auto
color.diff=auto

...

$ git config user.name
John Doe

$ git config - show-origin user.name
file:/home/johndoe/.gitconfig John Doe

In this example:

• git config — list shows all configuration settings.
• git config user.name displays the value of the user.name key.
• git config — show-origin user.nameindicates that the final value for user.name is John Doe, and it’s defined in the user’s /home/johndoe/.gitconfig file.

Getting Help in Git

You can get help in Git using three similar commands:

$ git help <verb>
$ git <verb> - help
$ man git-<verb>

For example, to learn more about git config , you can run:

$ git config — help

If you don’t want the in detail manual page help and just need a summary of the possible flags to use with the commands and learn more about its usage, you can pass the -h flag to the command:

$ git config -h
usage: git config [<options>]
Config file location
 - global use global config file
 - system use system config file
 - local use repository config file
 - worktree use per-worktree config file
-f, - file <file> use given config file
 - blob <blob-id> read config from given blob object
Action
 - get get value: name [value-pattern]
 - get-all get all values: key [value-pattern]
 - get-regexp get values for regexp: name-regex [value-pattern]
 - get-urlmatch get value specific for the URL: section[.var] URL
 - replace-all replace all matching variables: name value [value-pattern]
 - add add a new variable: name value
 - unset remove a variable: name [value-pattern]
 - unset-all remove all matches: name [value-pattern]
 - rename-section rename section: old-name new-name
 - remove-section remove a section: name
-l, - list list all
 - fixed-value use string equality when comparing values to 'value-pattern'
-e, - edit open an editor
 - get-color find the color configured: slot [default]
 - get-colorbool find the color setting: slot [stdout-is-tty]
Type
-t, - type <type> value is given this type
 - bool value is "true" or "false"
 - int value is decimal number
 - bool-or-int value is - bool or - int
 - bool-or-str value is - bool or string
 - path value is a path (file or directory name)
 - expiry-date value is an expiry date
Other
-z, - null terminate values with NUL byte
 - name-only show variable names only
 - includes respect include directives on lookup
 - show-origin show origin of config (file, standard input, blob, command line)
 - show-scope show scope of config (worktree, local, global, system, command)
 - default <value> with - get, use default value when missing entry

Conclusion

By now, you should’ve learned about:

• How to install Git
• How to setup and find configurations
• How to get help with the Git commands

In the next part of the ‘Become a Git Super User’ series, we’re going to cover how to create or clone a Git repo and everything about Git commits such as making commits, undoing them and viewing the history of your commits.

Thank you for reading this article. I appreciate your time and would love to hear your feedback. Please share your thoughts and opinions in the comment section below.

You can connect with me on LinkedIn, follow my projects on GitHub for more updates, or reach out to me on Twitter for ongoing discussions.

See you in the next articles …