Free tools Windows power users keep installed
One-click scans. No signup required.
The message git: command not found means the shell cannot resolve a Git executable for the account and environment that ran the command. Git may be absent, installed outside that account’s PATH, or available to an administrator but not to a service account. Identify which case applies, install Git with the server’s native package manager, start a fresh shell, and verify with git --version.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
This guide covers Ubuntu, Debian, Fedora, CentOS, RHEL-family systems, Alpine, Arch, openSUSE, Gentoo and Nix/NixOS, then shows what to check when an installation succeeds but an application still reports the same error.
As an Amazon Associate I earn from qualifying purchases.
What the error actually tells you
A shell reports git: command not found when command resolution fails. It has not found an executable named git in the directories listed in the current process’s PATH. That is narrower than saying Git is definitely uninstalled.
There are three practical causes:
- Git is not installed. The package was never added, was removed, or the server image does not include it.
- Git is installed but invisible to this shell. The executable may be in a custom directory that is missing from
PATH, or the shell may still have a stale command lookup cache. - A different environment is failing. A scheduled job, container, deployment hook or service account can have a different
PATHfrom the administrator’s interactive shell.
The fix is therefore a diagnosis, not a blind reinstall. First establish the distribution and the failing account, then test command discovery before changing the system.
#1 Best Overall
Use this fast decision path
- Read
/etc/os-releaseto identify the distribution and release family. - Run
command -v gitandtype -a gitas the account that receives the error. - If neither command returns a path, install Git from the distribution repository.
- Open a new shell (or reload the shell’s command lookup) and run
git --version. - If an interactive shell works but automation fails, inspect the service account, its
PATHand the executable path configured for that service.
| What you observe | Likely explanation | Next action |
|---|---|---|
command -v git prints nothing for every account |
Git is not installed or is outside all tested paths | Use the native package-manager command for the distribution |
| An administrator finds Git, but the application does not | The application runs as another user or with a restricted PATH |
Check that account’s environment and configure an absolute Git path where possible |
| Installation completed, but the current shell still fails | The shell has not refreshed its command lookup | Start a fresh shell or clear/reload the shell lookup, then verify again |
Git works by absolute path but not as git |
The directory containing Git is absent from PATH |
Add the correct directory to the intended account or service environment |
Identify the distribution and the account that is failing
Read the local release information
On most Linux servers, run:
cat /etc/os-releaseLook for fields such as ID, ID_LIKE and VERSION_ID. The package command must match the operating system family; using an unfamiliar command can fail even when you have administrative privileges.
Confirm which account and shell are involved
Run the diagnostic commands as the same user that reports the error. A command typed at an administrator prompt tests the administrator’s environment, not necessarily the account used by a web process, CI runner, scheduled task or deployment service. If the failure appears only in automation, reproduce it in that account’s environment or inspect the service definition for its user and environment settings.
Privileges matter during installation. Package-manager commands normally require root access, so use sudo when the server’s policy permits it, or have an administrator perform the installation.
Check whether Git is already discoverable
Use the shell’s resolution commands
Run both checks when troubleshooting:
command -v git
type -a gitA returned path, such as /usr/bin/git, proves that this shell can resolve a Git executable. If there is no output, the shell cannot find one through its current PATH. A result from type -a can also reveal multiple installations, which is important when a custom build shadows the distribution package.
Verify the executable, not just its name
When a path is returned, run:
git --versionThe command should print Git’s installed version. The alternative git version form also reports the version. If the path works only when entered explicitly, run that absolute path and compare the result with the bare command; this separates a broken executable from a PATH problem.
Install Git with the server’s package manager
The Git project describes the distribution package manager as the easiest Linux installation route in its Git installation guide. Repository packages integrate with the operating system’s updates, dependency tracking and security maintenance. Refresh package metadata first when your distribution requires it, then run the appropriate command below.
| Distribution or family | Installation command | Notes |
|---|---|---|
| Debian | sudo apt-get install git |
Uses Debian’s APT repositories; administrative privileges are required. |
| Ubuntu | sudo apt install -y git |
Ubuntu documents this noninteractive confirmation form. |
| Ubuntu (optional Snap path) | sudo snap install git-scm |
Use only when Snap is part of your server policy; the APT package is the usual repository route. |
| Fedora 22 and later | sudo dnf install git |
Refresh DNF metadata according to local policy when needed. |
| Older Fedora | sudo yum install git |
Older releases use the YUM command. |
| CentOS Stream and current RHEL-family systems | sudo dnf install git |
Use the package manager provided by that release; older CentOS installations may use YUM. |
| Older CentOS or RHEL-family release | sudo yum install git |
Repository availability depends on the release lifecycle and enabled repositories. |
| Arch Linux | sudo pacman -S git |
Pacman resolves the package from configured Arch repositories. |
| openSUSE | sudo zypper install git |
Use the repositories configured for the specific openSUSE edition. |
| Alpine Linux | apk add git |
Run as root or through the privilege method enabled on the image. |
| Gentoo | emerge --ask --verbose dev-vcs/git |
Portage resolves and builds the package according to Gentoo configuration. |
| Nix or NixOS | nix-env -i git |
Installation is managed through Nix rather than a conventional system package database. |
Debian and Ubuntu
On Debian, install with sudo apt-get install git. Ubuntu’s documentation shows sudo apt install -y git; the -y option accepts the package-manager confirmation prompt. Ubuntu also documents sudo snap install git-scm as an optional Snap package path. Choose one managed installation route rather than mixing packages without a reason, because multiple copies can make PATH and version selection confusing.
Fedora, CentOS and related systems
Fedora 22 and newer use sudo dnf install git. Older Fedora guidance uses yum. CentOS Stream and newer RHEL-family systems generally provide DNF, while older CentOS installations commonly provide YUM. The exact repositories available to an end-of-life release depend on its configured mirrors; if the package cannot be found, use a supported repository or consider the source-build fallback described below.
Arch, openSUSE, Alpine, Gentoo and Nix
Arch uses sudo pacman -S git; openSUSE uses sudo zypper install git; Alpine uses apk add git; Gentoo uses emerge --ask --verbose dev-vcs/git; and Nix/NixOS uses nix-env -i git. These commands assume the server has enabled repositories and network access appropriate to that distribution.
Refresh the shell and verify the installation
After the package manager reports success, do not assume every existing process has already noticed the new executable. Start a fresh login or interactive shell, then run:
Recommended Free Tools
command -v git
git --versionSome shells cache failed or successful command lookups. If you cannot open a new session immediately, use the shell’s command-hash refresh facility, such as hash -r in shells that support it, and test again. A fresh shell is preferable for a reliable check because it also loads the account’s current startup configuration.
If installation itself fails, read the package manager’s error rather than treating it as another Git problem. Typical branches are insufficient privileges, unavailable repositories, stale metadata, a release that has reached end of life, or blocked network access. Resolve that distribution-level issue first, then rerun the discovery and version checks.
When Git is installed but the shell still says “command not found”
Compare the failing account’s PATH
Print the environment for the account that fails and compare it with the account that succeeds:
printf '%sn' "$PATH"
command -v git
type -a gitIf Git is in a directory absent from the failing PATH, add that directory to the account’s normal startup configuration according to your shell and operating-system policy. Avoid copying an administrator’s entire environment into a service account; add only the required directory and preserve the service’s least-privilege design.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteLook for multiple installations
When type -a git lists more than one path, determine which one the failing process should use. A distribution package and a source build can have different versions and update schedules. Select deliberately, remove an obsolete copy only after confirming no other job depends on it, and verify the chosen path with git --version.
Rank #4
Distinguish a stale shell from a persistent PATH error
If a new shell resolves Git, the earlier failure was local to the old shell’s lookup state. If a new shell still fails but an absolute path works, the account’s startup configuration or service environment is missing the Git directory. If the absolute path also fails, confirm that the file still exists and that the account has permission to execute it.
Fix failures in services, jobs and deployment automation
An administrator’s successful test does not prove that a daemon or scheduled job can run Git. Services often start with a minimal, explicitly defined environment and a different user.
- Identify the account under which the failing service, timer, job or hook runs.
- Inspect that account’s
PATHand runcommand -v gitin an equivalent environment. - Find the absolute Git path that works for that account, then configure the service or script to use that path where the service format allows it.
- Restart or reload the service using the operating system’s normal procedure so it receives the updated environment.
- Retest the actual job, not only an administrator’s terminal command.
Using an absolute path is often the most predictable option for automation because it avoids differences between login-shell startup files and noninteractive service environments. Keep the path recorded in deployment documentation; a later package change or source-build migration can otherwise leave the service pointing at a removed executable.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsBuild Git from source only when a package is unsuitable
The Pro Git installation chapter documents both package installation and source compilation. A source build is a fallback when the repository package is unavailable, too old for a documented requirement, or when you need a controlled custom prefix.
Understand the trade-offs first
- More control: you choose the source version and installation prefix.
- More prerequisites: compilers, headers and other build dependencies must be installed before configuration.
- More maintenance: the distribution package manager will not automatically track the custom binary, upgrades and security fixes.
- More PATH responsibility: the account or service that runs Git must be able to reach the prefix’s
bindirectory.
Follow the documented build sequence
Use the dependency examples for your package family in Pro Git, then obtain the Git source release appropriate for your requirement. The documented build flow is:
Best Value
./configure
make
make installRun installation with the privileges required by the chosen prefix. A system-wide prefix generally needs administrative access; a user-owned prefix can avoid that requirement but must be included in the user or service account’s PATH. Record the exact prefix and source version, and verify the resulting executable with its absolute path before changing any shared service configuration.
Package installation versus a source build
| Decision factor | Distribution package | Source build |
|---|---|---|
| Availability | Available when the configured distribution repository carries Git | Useful when repositories are unavailable or do not meet a documented version requirement |
| Version choice | Typically follows the release’s repository policy | You select the source release and compile it yourself |
| Privileges | Usually requires root or sudo to install system-wide |
System-wide installation requires privileges; a custom user prefix can reduce that need |
| Maintenance | Updates, dependency tracking and removal fit the operating system’s package tools | You must track upgrades, dependencies, the prefix and removal procedures |
| Automation environment | Often lands in a standard system directory, but the service still needs a suitable PATH |
The service must be given the custom bin directory or an absolute executable path |
For a normal server installation, use the repository package. Choose source compilation only when its control or availability advantage outweighs the added operational work.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Common failure modes and precise fixes
Using the wrong package command
An apt command on Alpine or a pacman command on Debian will not install Git. Recheck /etc/os-release and use the matching command table entry.
Installing as an administrator and testing as another user
Package installation is system-wide in the usual repository path, but command resolution still depends on each process’s environment. Test as the account that will actually execute Git, especially for services and deployment jobs.
Assuming a package-manager success message updates running services
Already-running processes keep their original environment. Start a new shell and restart or reload the affected service through its normal operational procedure before retesting.
Leaving an old custom build ahead of the package
Multiple paths can produce an unexpected version. Use type -a git, choose the intended executable, and document the decision. Do not delete a binary until you know which jobs reference it.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Ignoring repository and release support
On an old or end-of-life server, the package may not be available from its configured mirrors. Updating repository configuration or the operating system may be safer than forcing an untracked binary. If policy requires a custom version, use the source-build process and maintain its dependencies deliberately.
Final verification checklist
- The distribution was identified from
/etc/os-release. - The failing account was tested, not only an administrator account.
command -v gitreturns the intended executable.type -a gitwas checked for conflicting installations.git --versionsucceeds in a fresh shell.- Any service, timer, hook or automation account has a usable
PATHor an explicit absolute Git path. - A source build, if used, has a recorded prefix, source version and upgrade plan.
For the official command list, see Git – Install for Linux. For the package-versus-source workflow and build sequence, see Pro Git: Installing Git. Ubuntu’s package and optional Snap instructions are documented at Using Git version control on Ubuntu.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
