On Debian and Ubuntu the command is sudo apt update and then sudo apt install git. On Fedora, RHEL and derivatives it is sudo dnf install git. On Arch it is sudo pacman -S git, and on Alpine it is sudo apk add git. All four finish in under a minute, and the only thing worth checking afterwards is which version the distribution decided to give you, because on long-term-support releases that version can be several years behind.
Installing Git is the easy part and almost nobody gets stuck on it. Where people do get stuck is the ten minutes afterwards: an ancient version missing a subcommand they read about, a first commit rejected because the identity is unset, and an authentication prompt asking for a password that has not worked since token authentication replaced it.
Table of contents
- The command for your distribution
- Check what you actually installed
- When the packaged version is too old
- The first-run configuration nobody mentions
- Authentication: keys and tokens, not passwords
- Workstation install versus server install
- How this fits the rest of the stack
- FAQ
The command for your distribution
Git is in the default repositories everywhere. There is no PPA to add and no download page to visit for the standard case.
# Debian, Ubuntu, Mint, Pop!_OS, Raspberry Pi OS
sudo apt update && sudo apt install git
# Fedora, RHEL 8+, Rocky, Alma, CentOS Stream
sudo dnf install git
# Older RHEL and CentOS 7
sudo yum install git
# Arch, Manjaro, EndeavourOS
sudo pacman -S git
# openSUSE
sudo zypper install git
# Alpine
sudo apk add git
# Void
sudo xbps-install -S gitTwo package names cause confusion. The plain git package is the command-line tool and is what you want. The git-all package on Debian-family systems, and git-all on Fedora, pulls in every optional component including the graphical tools, the email bridge and the CVS import helpers. On a workstation that is harmless. On a server it installs a large amount of software you will never run.
If the machine has no package manager access at all, Git can be installed into a home directory from source, but that is a last resort and covered further down.
Check what you actually installed
This is the step most guides skip, and it is the one that explains most later confusion.
git --version
which -a gitDistribution packages lag upstream, and long-term-support releases lag it badly. A five-year-old LTS can ship a Git that predates several now-standard features. Things you will notice missing or behaving differently on an old version:
- git switch and git restore, the modern replacements for the overloaded checkout command.
- The default branch name setting, so every new repository is created as master regardless of your preference.
- Partial clone and sparse checkout options that make large repositories usable.
- Credential helper behaviour, which changed when token authentication became mandatory on most hosts.
- Security fixes. This is the one that actually matters, and it is the reason to check rather than assume.
The second command matters when there are two installs. A Git in /usr/local/bin from an earlier source build will shadow the packaged one in /usr/bin, and you will be running a version you forgot about.
When the packaged version is too old
On Ubuntu the maintained backport is the usual answer, and it stays updated through the normal upgrade path rather than needing manual rebuilds.
sudo add-apt-repository ppa:git-core/ppa
sudo apt update
sudo apt install git
git --versionOn RHEL-family systems the equivalent is a module stream or a third-party repository, and both come with the usual caveat that you are now trusting an additional package source on a machine that probably exists because someone wanted a small trusted set.
Building from source is the portable option and is less painful than it sounds, roughly five minutes on a modern machine.
sudo apt install -y build-essential libssl-dev libcurl4-gnutls-dev libexpat1-dev gettext
curl -sL https://github.com/git/git/archive/refs/tags/v2.47.0.tar.gz -o git.tar.gz
tar -xzf git.tar.gz && cd git-2.47.0
make prefix=/usr/local all
sudo make prefix=/usr/local installInstalling to /usr/local rather than /usr keeps the packaged version intact underneath, so the fallback is a PATH change rather than a reinstall. Remember that a source build does not receive security updates automatically, which makes it a poor choice for a long-lived server and a fine one for a workstation you maintain deliberately.
The first-run configuration nobody mentions
A fresh install will refuse to commit until it knows who you are, and the error appears at the worst possible moment, which is after you have written the commit message.
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
# Stop new repositories defaulting to master
git config --global init.defaultBranch main
# Never guess on pull; fail loudly instead of silently merging or rebasing
git config --global pull.rebase false
# Keep line endings sane when working with people on Windows
git config --global core.autocrlf input
# Make the diff readable
git config --global core.pager "less -FRX"The email address matters more than it looks. Hosting platforms match commits to accounts by the commit email, so a mismatch produces a history full of commits that are not attributed to you and cannot be retroactively fixed without rewriting the history.
Everything set with —global lands in ~/.gitconfig, which is worth keeping in a dotfiles repository so a new machine is configured in one command rather than rediscovered every time.
Authentication: keys and tokens, not passwords
Password authentication over HTTPS was removed by the major hosts. If a clone or push is prompting for a password and rejecting the right one, this is why.
Two working options. SSH keys are the better default for a machine you use regularly.
ssh-keygen -t ed25519 -C "[email protected]"
cat ~/.ssh/id_ed25519.pub # add this to the host's SSH keys page
ssh -T [email protected] # verifyPersonal access tokens are the option for HTTPS remotes, CI runners and anywhere an SSH key is impractical. Generate one on the host, use it in place of the password, and cache it so it is entered once.
# Cache in memory for an hour
git config --global credential.helper "cache --timeout=3600"
# Or store on disk, plaintext -- acceptable only on a machine you control
git config --global credential.helper storeOn a shared or multi-user server, prefer the cache helper or a per-repository deploy key. The store helper writes the token to a plain file in the home directory, and on a machine other people can read that is an account compromise waiting to be noticed.
Workstation install versus server install
The same package, two quite different sets of decisions.
On a workstation, install the plain package, add the backport if the distribution version is old, set the global config, and generate an SSH key. Done in five minutes and you will not think about it again.
On a server the questions are different, and the most useful one is whether Git should be there at all.
- If the server is a build machine, install Git and use a read-only deploy key scoped to the single repository it needs, not a personal account key.
- If the server is running the application, it usually does not need Git. Deploy an artefact rather than pulling a repository, so production has no credentials and no working tree to drift.
- If you are pulling on the server anyway, use a shallow clone to save space and time, and never store a personal token in the credential store on a machine other people can access.
git clone --depth 1 --branch main [email protected]:org/repo.gitThe pattern where production pulls from a repository is common, understandable and slowly deprecating itself, because it puts a credential and an editable working copy on the box you least want either on. A build step that produces an artefact and a deploy step that ships it is more work once and less risk permanently.
How this fits the rest of the stack
The end of the local setup is usually the start of a deployment question: the repository exists, it is authenticated, and something now has to build and run it. Costing that is worth doing before the pipeline is built, and the RunxBuild hosting calculator lists the parts separately so the service, the database, the storage and the bandwidth are visible as individual numbers. On RunxBuild a service deploys straight from a GitHub repository with build logs, environment variables, a live route and a rollback to the previous deploy, which removes the case for keeping Git credentials on the production machine at all.
Useful related references:
- How to Rename a File in Linux: mv, rename, and git mv
- hostnamectl set-hostname: How to Set the Hostname in Linux
- Change the Hostname on a Linux Machine Permanently
- Services on RunxBuild
FAQ
What is the command to install Git on Ubuntu from the terminal?
sudo apt update followed by sudo apt install git. The update step matters on a machine that has not been touched recently, because apt will otherwise try to fetch a version that is no longer in the mirror index and fail with a confusing 404.
How do I check which version of Git I have?
Run git —version. Also run which -a git, because a source build in /usr/local/bin shadows the packaged one in /usr/bin, and you can end up running a version you installed and forgot about years earlier.
Should I install git or git-all?
Install git. The git-all package pulls in optional components including graphical tools and the email bridge, which is fine on a workstation and unnecessary weight on a server. You can always add the extras later if something needs them.
Why does Git ask for a password that does not work?
The major hosts removed password authentication over HTTPS. Use an SSH key for a machine you use regularly, or a personal access token in place of the password for HTTPS remotes. Cache the token with a credential helper so it is entered once.
Is it safe to build Git from source?
It is safe and takes about five minutes, but a source build receives no security updates automatically. That makes it reasonable on a workstation you maintain deliberately and a poor choice on a long-lived server, where a maintained backport repository is the better answer.