Installing & Configuring Git

Git is the version control system (a tool that tracks every change you make to your files so you can review history, undo mistakes, and collaborate without overwriting each other’s work) that almost every DevOps workflow depends on. Before you can clone a repository, push code, or wire up a deployment pipeline, you need Git installed and told who you are. This page walks you through installing Git on Ubuntu, setting your global configuration, verifying the install, and creating an SSH key so you can talk to GitHub securely.

When to use this

You install and configure Git the very first time you set up a machine for development — whether that is your laptop or a fresh Ubuntu server you just provisioned. You do this once per machine, not once per project. The identity you set (name and email) is stamped onto every commit you make on that machine, so it is worth getting right early.

You do not need to repeat the global configuration for each repository. The only time you override it per-project is when one repo needs a different email (for example, a work account vs a personal one) — and even then you only change that single setting inside that one folder.

Installing Git on Ubuntu

Ubuntu ships with apt, the Advanced Package Tool (the program that installs and updates software on Debian-based Linux systems). Git lives in the default Ubuntu repositories, so installation is a two-step process: refresh the package list, then install.

sudo apt update
sudo apt install -y git

sudo runs the command as the administrator (the superuser), which is required to install system-wide software. The -y flag answers “yes” automatically so the install does not pause to ask for confirmation.

Output:

Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  git
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Setting up git (1:2.43.0-1ubuntu7.1) ...

The version Ubuntu installs is usually a few months behind the very latest Git release, which is perfectly fine for almost everyone. If you specifically need the newest features, you can add the official Git PPA (Personal Package Archive — a third-party repository maintained by the Git team):

sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install -y git

Only add PPAs you trust. A PPA can ship any software it likes to your machine, so stick to well-known, official sources like git-core/ppa.

Verifying the install

Always confirm the install worked before moving on. The --version flag prints the installed version and exits.

git --version

Output:

git version 2.43.0

If you see a version number, Git is on your PATH (the list of folders your shell searches for programs) and ready to use. If instead you see git: command not found, the install did not finish — re-run the apt install step.

Configuring your identity and defaults

Git records who made each change. Until you tell it your name and email, every commit is attributed to a guessed username and hostname, which looks messy in shared history. You set these with git config --global. The --global flag writes the setting to your user-level config file at ~/.gitconfig, so it applies to every repository for your user.

git config --global user.name "Jane Developer"
git config --global user.email "[email protected]"

Use the same email here that you use on GitHub or GitLab — that is how those platforms link your commits to your account and show your avatar.

Next, set a few sensible defaults. The default editor is what Git opens when it needs you to type a message (for example, during a merge). New Git users are often dropped into vim by accident and get stuck; setting nano avoids that.

git config --global core.editor "nano"
git config --global init.defaultBranch main
git config --global pull.rebase false

Here is what each setting does:

Setting	What it controls	Recommended value
user.name	Name stamped on your commits	Your real name
user.email	Email stamped on your commits	The email on your Git host
core.editor	Editor Git opens for messages	nano (or vim/code --wait)
init.defaultBranch	Name of the first branch in a new repo	main
pull.rebase	Whether git pull rebases or merges	false (merge) for beginners

To see everything you have set, list the config. The --list flag prints every active setting, and --show-origin tells you which file each one came from.

git config --global --list

Output:

user.name=Jane Developer
[email protected]
core.editor=nano
init.defaultBranch=main
pull.rebase=false

Setting up an SSH key for GitHub

To push and pull code without typing a password every time, you authenticate with an SSH key (a matched pair of cryptographic files — a private key you keep secret and a public key you share). You generate the pair once, add the public half to GitHub, and Git uses it silently after that.

Generate a modern Ed25519 key (a fast, secure key type that is the current recommended default):

ssh-keygen -t ed25519 -C "[email protected]"

Output:

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/jane/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Your identification has been saved in /home/jane/.ssh/id_ed25519
Your public key has been saved in /home/jane/.ssh/id_ed25519.pub

Press Enter to accept the default path (~/.ssh/id_ed25519). A passphrase is optional but adds a second layer of protection if someone ever copies your private key.

Then print the public key and paste it into GitHub under Settings -> SSH and GPG keys:

cat ~/.ssh/id_ed25519.pub

Never share or commit the private key (~/.ssh/id_ed25519, with no .pub). Only the .pub file goes to GitHub. Anyone with your private key can act as you. The full SSH setup, including the SSH agent and testing the connection, is covered on the dedicated SSH and remotes pages.

Best Practices

• Set user.name and user.email immediately after installing — clean commit history starts on day one.
• Use the same email across Git, GitHub, and GitLab so your contributions are correctly linked.
• Prefer SSH keys over HTTPS passwords for day-to-day work; they are more secure and far more convenient.
• Generate ed25519 keys, not the older rsa type, unless a system specifically requires RSA.
• Add a passphrase to your SSH key on shared or laptop machines that could be lost or stolen.
• Run git config --global --list after setup to confirm everything saved as you expected.
• Keep your private key permissions tight; ~/.ssh should be 700 and the key file 600 (Git and SSH enforce this).

Related Topics

• What is version control?
• Git basics
• Working with remotes
• GitHub & GitLab
• Ignoring files with .gitignore