iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
The error means the shell cannot resolve an executable named git. Git is either not installed, its directory is missing from the failing account’s PATH, or a service is using a different environment from your administrator shell. Identify the distribution and account first, install Git with that distribution’s package manager, then verify with git --version. If an automated job still fails, test Git as the service account and configure an absolute path or an appropriate service PATH.
This procedure applies to common Debian, Ubuntu, Fedora, RHEL-derived, Arch, openSUSE, Alpine, Gentoo and Nix/NixOS servers. Commands that install packages normally require root privileges through sudo.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errors
What “git: command not found” actually tells you
A shell resolves a command by searching each directory listed in the current account’s PATH. The message is therefore a command-resolution failure, not a Git repository error. It occurs before Git can read a repository, authenticate to a remote, or report a Git-specific configuration problem.
There are three practical causes:
- Git is absent. No Git executable is installed on the server, or the package was removed.
- Git is installed outside
PATH. A custom installation may be under a prefix such as/usr/local, while the account’s shell searches only system directories. - The failing process has a different environment. A systemd unit, cron job, container, deployment runner or restricted login can use another account and a shorter
PATHthan your interactive administrator session.
Do not solve this by copying a binary at random. First establish which of these cases applies; the correct fix depends on the distribution, installation method and account that will run Git.
#1 Best Overall
Identify the server and the failing context
Read the distribution identity
On most modern Linux systems, run:
cat /etc/os-releaseLook at fields such as ID, VERSION_ID and PRETTY_NAME. They determine which package manager and repository instructions are appropriate. If you are inside a container, check the file inside that container; the host distribution does not determine the container’s package manager.
Check whether the current shell can find Git
Run these commands as the account that produced the error:
Recommended Free Tools
command -v git
type -a git
printf '%sn' "$PATH"
whoami
git --versioncommand -v prints the path that would be executed, or nothing when the command is not discoverable. type -a can reveal aliases, functions and multiple Git binaries. If git --version succeeds, the original failure came from another shell, account or execution environment rather than from this session.
Check privileges before installing
Package installation generally needs root access. Confirm that the account can use sudo, or switch to a root shell according to your organization’s policy. A successful command in an administrator shell does not automatically make Git available to an unprivileged service account.
Install Git from the distribution repository
The Git project describes the distribution package manager as the easiest Linux installation route in its Git installation guide. Repository packages receive the distribution’s normal security updates and integrate with its file layout and dependency database.
| Distribution | Installation command | Operational notes |
|---|---|---|
| Debian or Ubuntu | sudo apt-get install git |
Refresh APT metadata first when the server’s package lists are stale. |
| Fedora 22 and later | sudo dnf install git |
Older Fedora releases use yum; those releases are generally outside current support windows. |
| Arch Linux | sudo pacman -S git |
Use the normal Arch update policy before installing on a long-unupdated system. |
| openSUSE | sudo zypper install git |
zypper resolves the package from configured repositories. |
| Alpine Linux | apk add git |
Run as root or prefix with the equivalent privilege mechanism. |
| Gentoo | emerge --ask --verbose dev-vcs/git |
The command displays the planned merge and asks for confirmation. |
| Nix or NixOS | nix-env -i git |
Nix profiles determine which user or system environment receives the executable. |
Debian and Ubuntu
On Debian, Ubuntu and derivatives, refresh package metadata if the machine has not updated it recently, then install Git:
sudo apt-get update
sudo apt-get install gitUbuntu’s documentation also shows the noninteractive confirmation form:
sudo apt install -y gitThe -y option answers the package manager’s confirmation prompt; it does not bypass repository or privilege errors. Ubuntu documents an optional Snap route, sudo snap install git-scm, but the APT package is normally simpler for server automation because it follows the host’s standard package database and paths. Use the Snap form only when Snap is installed and its confinement and command location fit the service that will run Git. See Canonical’s Ubuntu Git documentation for the documented alternatives.
Fedora and RHEL-family systems
Fedora 22 and newer use DNF:
sudo dnf install gitOn older Fedora systems, the historical package command is yum. RHEL-derived systems may require enabled repositories that are specific to the release and subscription. If DNF reports that no package is available, confirm the release, repository configuration and network access before attempting a source build.
Arch Linux
Install the package with:
sudo pacman -S gitArch is a rolling distribution. On a machine that has been offline or unupdated for a long time, follow the normal full-system update policy rather than mixing an old local package database with new packages. Resolve any keyring or mirror errors first; they are repository-management problems, not Git command-resolution problems.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →openSUSE
Use the configured Zypper repositories:
sudo zypper install gitIf Zypper cannot find Git, inspect enabled repositories and the release version. Do not substitute a package from a different openSUSE release merely to make the command succeed.
Alpine Linux
Alpine uses the apk package manager:
apk add gitMinimal Alpine images may not include sudo, so run the command as root. If the image is rebuilt on every deployment, add Git to the image definition rather than installing it manually in a running container.
Gentoo
Gentoo’s documented package atom is:
emerge --ask --verbose dev-vcs/git--verbose shows the selected package and USE-flag decisions, while --ask pauses for confirmation. Complete any pending dependency or profile updates according to the host’s Gentoo maintenance policy.
Nix and NixOS
The Git project lists:
nix-env -i gitNix installs into a profile rather than necessarily placing a file in a traditional global directory. Install it into the same user or system profile used by the process that will invoke Git, and verify that profile’s environment is loaded by that process.
Reload the shell and verify the installation
After the package manager reports success, use this sequence:
- Start a fresh login shell or reconnect over SSH. This removes stale session assumptions and loads the account’s normal startup files.
- If you cannot start a new shell, ask the current shell to forget its cached command locations. For POSIX shells that support it, run
hash -r; then runcommand -v gitagain. - Verify the executable and version with
git --version. The output should contain a Git version instead of a command-not-found message. - Confirm the exact binary used by the account with
type -a git. This catches an unexpected older copy earlier inPATH.
Do not treat a package-manager exit message alone as proof that every account can run Git. The decisive test is git --version in the same account and environment as the failing operation.
Git is installed, but the shell still cannot find it
Compare the executable’s location with PATH
From an account that can run Git, obtain its path:
command -v git
readlink -f "$(command -v git)"
printf '%sn' "$PATH"If the resolved file is in a directory absent from the failing account’s PATH, add that directory through the account’s supported shell configuration or invoke the absolute path. Prefer a system-wide, package-managed location for a system service; do not rely on a developer’s personal shell startup file.
Check shell startup differences
Interactive, login and noninteractive shells read different startup files. A line that exports PATH in a user’s interactive configuration may never run for a cron job or service. Compare environments explicitly:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
env | grep '^PATH='
/usr/bin/env -i HOME="$HOME" PATH=/usr/bin:/bin command -v gitThe second command intentionally uses a minimal path. It demonstrates whether Git is available in standard system directories without inheriting unrelated shell settings. Adjust the path only in the environment that actually launches Git, and keep existing system directories when adding a custom prefix.
Account and privilege changes can alter resolution
sudo may apply a configured secure path, and switching users may load a different home directory and profile. Test both sides rather than assuming the administrator’s result applies to the target account:
sudo -u SERVICE_USER -- sh -lc 'whoami; printf "%sn" "$PATH"; command -v git; git --version'Replace SERVICE_USER with the real account. If that account cannot execute Git, either install the package system-wide, grant access to the custom installation directory, or configure the service with the correct path. Avoid giving the service unnecessary administrator privileges merely to make command lookup work.
Rank #4
When only a service, cron job or deployment runner fails
A common pattern is: an administrator runs git --version successfully, but an application reports git: command not found. The application may run as a dedicated user, inside a container, or under a systemd unit with a deliberately restricted environment.
Crashes, 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 minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallTest the service’s account and environment
Run the same command as the service account, using the same filesystem namespace where possible. For a systemd unit, inspect its configured identity and environment with your distribution’s service-management tools, then check the unit’s logs for the exact command and working directory. The key values are:
- the account specified by the unit’s user setting;
- the unit’s effective
PATHor environment entries; - whether Git is installed inside the service’s container or chroot;
- whether the service can read the repository and its parent directories.
Use an absolute path when the service supports it
Once command -v git identifies the trusted executable, configure the job or unit to call that absolute path, such as /usr/bin/git when that is the path on your server. This avoids dependence on interactive shell files. If the service invokes scripts that themselves call git, set an explicit PATH for the service or change those scripts to use the approved absolute path.
Reload service configuration safely
After changing a systemd unit or environment drop-in, reload the manager configuration and restart only the affected service according to your change-control process. Then inspect the service logs and reproduce the operation as the service account. A successful administrator test is not a substitute for an end-to-end service test.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Building Git from source when packages are unsuitable
Source compilation is a fallback, not the first response to a missing command. Use it when the repository package is unavailable, too old for a documented requirement, or when you need a controlled custom prefix. The Pro Git installation chapter explains both package installation and source builds, including dependency examples for DNF- and APT-based systems.
Free tools Windows power users keep installed
One-click scans. No signup required.
Plan the prefix and ownership first
Choose where the files will live, record that prefix in your operational documentation, and decide which account needs to execute Git. A shared location such as /usr/local can serve multiple accounts; a user profile limits visibility to one account. The resulting bin directory must be in the target account’s PATH, or the service must call the absolute path.
Install build dependencies
Install the compiler, development libraries and other prerequisites listed for your distribution in the Pro Git instructions. Dependency names differ by release, so do not copy a package list intended for another distribution. Ensure the source archive is obtained through your organization’s approved channel and that the build account has adequate temporary disk space.
Best Value
Configure, compile and install
The documented build flow is:
./configure
make
sudo make installRun ./configure from the extracted Git source directory. Review its output for missing libraries before compiling. make builds the selected version; make install writes files to the configured prefix and normally requires elevated privileges when that prefix is system-wide. If you need a non-default location, provide the prefix option supported by the Git build system, then place that prefix’s bin directory in the executing account’s environment.
Maintain a source installation
A source build does not automatically receive the distribution’s security updates. Record the Git version, source origin, compiler environment and prefix; plan how upgrades and removals will be performed; and make sure only the intended executable precedes the distribution package in PATH. Re-run git --version and type -a git after every upgrade.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Package installation versus a source build
| Decision factor | Distribution package | Source build |
|---|---|---|
| Availability | Depends on configured repositories and the distribution release. | Requires source code, compiler tools and development dependencies. |
| Version | Version selected and supported by the distribution; it may lag upstream. | Can provide a newer or specifically controlled version. |
| Privileges | Usually requires root or sudo to install system-wide. |
Needs elevated access for a shared prefix; a user prefix can avoid that but affects only that profile. |
| Maintenance | Updates, file ownership and removal are handled by the package manager. | You must track upgrades, dependencies, files and security maintenance. |
| Automation compatibility | Usually lands in standard system directories. | You must expose the chosen bin directory to every service or account that invokes Git. |
For a normal server, choose the native package unless a documented version or deployment requirement justifies the additional maintenance of a source build.
Common failure modes and targeted fixes
“Package not found”
Recheck /etc/os-release, enabled repositories, release support and network or proxy settings. The installation command must match the actual distribution; an Ubuntu command will not repair an Alpine image.
Permission denied during installation
Use an authorized root or sudo account. Do not make package directories world-writable. If policy forbids system installation, use a controlled user prefix and configure the consuming service explicitly.
Git works after SSH but not in a script
Scripts may run noninteractively with a smaller PATH. Use an absolute executable path or set a complete path in the script’s environment, then test under the same account and scheduler.
Git works for root but not for an application
Check the application’s user, namespace, filesystem visibility and path. Install Git inside the relevant container or configure the host service to use the host executable only when that arrangement is intentional.
The wrong Git version runs
type -a git lists every candidate found. Remove stale custom entries from the target account’s PATH, or put the approved executable first and document why. Verify again with git --version.
Quick Recap
Final verification checklist
/etc/os-releaseidentifies the server distribution.- The installation command came from that distribution’s supported package path.
command -v gitreturns the intended executable for the failing account.git --versionsucceeds in the same shell, container or service context.- Automated jobs use an explicit, working
PATHor absolute Git path. - A source installation, if used, has a recorded prefix and an upgrade plan.
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.
