This guide walks you through installing Git on RHEL 10, Rocky Linux 10, and AlmaLinux 10. We cover two methods – installing from the default AppStream repository for a quick setup, and building from source when you need the latest Git 2.47+ release. After installation, we configure Git for daily use, set up SSH keys, and cover common workflows.
Git is the standard distributed version control system used across the industry. Whether you are managing infrastructure-as-code, application source, or dotfiles, having a properly configured Git installation is one of the first things you do on a fresh server.
Prerequisites
Before you begin, make sure you have the following in place:
- A running installation of RHEL 10, Rocky Linux 10, or AlmaLinux 10
- A user account with
sudoprivileges (or root access) - An active internet connection to download packages or source tarballs
- Basic familiarity with the Linux command line
Start by making sure your system packages are up to date:
sudo dnf update -y
Method 1 – Install Git from AppStream Repository (Quick)
The fastest way to get Git running on RHEL 10 and its derivatives is to install the package from the default AppStream repository. This gives you a stable, vendor-supported version that receives security patches through your normal update cycle.
Step 1: Install Git with dnf
Run the following command to install Git:
sudo dnf install git -y
This pulls in Git and all required dependencies from the AppStream repository that ships with RHEL 10 / Rocky Linux 10 / AlmaLinux 10.
Step 2: Verify the installation
Confirm that Git is installed and check the version:
git --version
You should see output similar to:
git version 2.46.x
The exact version depends on the packages available in your distribution’s AppStream at the time of installation. If you need a newer release – for example Git 2.47 or later – proceed to Method 2 below.
Method 2 – Build Git from Source (Latest Version)
When you need features or fixes from the latest Git release, building from source is the way to go. This method gives you full control over the version you run. At the time of writing, the latest stable release is in the Git 2.48.x series.
Step 1: Install build dependencies
Git requires several development libraries and tools to compile. Install them all in one shot:
sudo dnf install -y make gcc curl-devel expat-devel gettext-devel openssl-devel zlib-devel perl-ExtUtils-MakeMaker autoconf asciidoc xmlto docbook2X tar wget
If you already have an older Git installed from the repository and want to replace it cleanly, remove it first:
sudo dnf remove git -y
Step 2: Download the latest Git source
Head over to the Git releases page on GitHub to find the latest version tag. Then download and extract it. Replace the version number below with the latest available:
GIT_VERSION="2.48.1"
cd /usr/src
sudo wget https://github.com/git/git/archive/refs/tags/v${GIT_VERSION}.tar.gz -O git-${GIT_VERSION}.tar.gz
Extract the downloaded archive:
sudo tar -xzf git-${GIT_VERSION}.tar.gz
cd git-${GIT_VERSION}
Step 3: Compile and install
Build Git from source and install it to /usr/local:
sudo make prefix=/usr/local all
sudo make prefix=/usr/local install
The prefix=/usr/local flag installs the binary to /usr/local/bin/git, which keeps it separate from any distro-packaged version in /usr/bin.
Step 4: Verify the source build
Make sure the newly compiled Git binary takes priority. Check your shell’s PATH resolution and the version:
which git
git --version
Expected output:
/usr/local/bin/git
git version 2.48.1
If which git returns /usr/bin/git instead, it means /usr/local/bin is not ahead of /usr/bin in your PATH. Fix this by adding the following to your shell profile (~/.bashrc or ~/.bash_profile):
export PATH="/usr/local/bin:$PATH"
Then reload the profile:
source ~/.bashrc
Initial Git Configuration
After installing Git, configure your identity and preferences. These settings are stored in ~/.gitconfig and apply globally to all repositories for your user.
Set your name and email
Every Git commit records the author’s name and email. Set these to match your GitHub, GitLab, or work identity:
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
Set the default branch name
Modern convention uses main as the default branch name. Configure Git to use it when initializing new repositories:
git config --global init.defaultBranch main
Set your preferred editor
Git opens an editor for commit messages, interactive rebases, and other tasks. Set it to your preferred choice:
# Use vim (default on most systems)
git config --global core.editor "vim"
# Or use nano if you prefer something simpler
git config --global core.editor "nano"
Configure the credential helper
If you work with HTTPS remotes, a credential helper avoids retyping your password on every push or pull. The store helper saves credentials in a plaintext file, while cache holds them in memory for a set period:
# Cache credentials in memory for 1 hour (3600 seconds)
git config --global credential.helper 'cache --timeout=3600'
# Or store credentials permanently (less secure, but convenient for CI/automation)
git config --global credential.helper store
Verify your configuration
Review all global settings to confirm everything is correct:
git config --global --list
Sample output:
user.name=Your Name
[email protected]
init.defaultbranch=main
core.editor=vim
credential.helper=cache --timeout=3600
Set Up SSH Keys for GitHub / GitLab
SSH key authentication is the preferred way to interact with remote Git repositories. It is more secure than passwords and does not require a credential helper.
Step 1: Generate an SSH key pair
Create an Ed25519 key (recommended for its security and performance):
ssh-keygen -t ed25519 -C "[email protected]"
Press Enter to accept the default file location (~/.ssh/id_ed25519). Optionally set a passphrase for an extra layer of security.
Step 2: Start the SSH agent and add your key
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
Step 3: Copy your public key
Display the public key so you can copy it:
cat ~/.ssh/id_ed25519.pub
Copy the entire output line.
Step 4: Add the key to your Git hosting provider
- GitHub – Go to Settings > SSH and GPG keys > New SSH key, paste the key, and save.
- GitLab – Go to Preferences > SSH Keys, paste the key, and click Add key.
Step 5: Test the connection
# For GitHub
ssh -T [email protected]
# For GitLab
ssh -T [email protected]
A successful test returns a greeting message confirming authentication. For GitHub, you will see something like:
Hi username! You've successfully authenticated, but GitHub does not provide shell access.
Common Git Workflows
Here is a quick reference for the day-to-day Git operations you will use most often.
Clone a repository
# Clone via SSH (preferred)
git clone [email protected]:username/repository.git
# Clone via HTTPS
git clone https://github.com/username/repository.git
# Clone into a specific directory
git clone [email protected]:username/repository.git /path/to/directory
Work with branches
# List all branches (local and remote)
git branch -a
# Create and switch to a new branch
git checkout -b feature/my-new-feature
# Switch to an existing branch
git checkout main
# Delete a local branch after merging
git branch -d feature/my-new-feature
Stage, commit, and push changes
# Check the current status
git status
# Stage specific files
git add file1.txt file2.txt
# Stage all changes in the current directory
git add .
# Commit with a message
git commit -m "Add user authentication module"
# Push the current branch to the remote
git push origin feature/my-new-feature
Pull and merge changes
# Pull latest changes from remote
git pull origin main
# Merge a feature branch into main
git checkout main
git merge feature/my-new-feature
# Rebase your feature branch on top of the latest main
git checkout feature/my-new-feature
git rebase main
View history and diffs
# View commit log (compact)
git log --oneline --graph --decorate
# Show changes in the working directory
git diff
# Show changes that are staged for commit
git diff --cached
# Show a specific commit
git show abc1234
Git Aliases for Productivity
Aliases let you shorten frequently used commands. After years of typing these commands daily, these are the ones I find most useful:
# Short status
git config --global alias.st status
# Compact log with graph
git config --global alias.lg "log --oneline --graph --decorate --all"
# Amend the last commit without editing the message
git config --global alias.amend "commit --amend --no-edit"
# Show a pretty diff of staged changes
git config --global alias.ds "diff --cached"
# Shortcut for checkout
git config --global alias.co checkout
# Shortcut for branch
git config --global alias.br branch
# Shortcut for commit
git config --global alias.ci commit
# Unstage a file
git config --global alias.unstage "reset HEAD --"
# Show last commit
git config --global alias.last "log -1 HEAD"
After setting these up, you can use them immediately:
# Instead of: git status
git st
# Instead of: git log --oneline --graph --decorate --all
git lg
# Instead of: git checkout -b new-feature
git co -b new-feature
Troubleshooting
git: command not found
If you get a “command not found” error after building from source, /usr/local/bin is likely not in your PATH. Add it:
echo 'export PATH="/usr/local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
Permission denied (publickey) when pushing
This means SSH key authentication failed. Verify that:
- Your SSH key is added to the agent:
ssh-add -l - The public key is uploaded to GitHub/GitLab
- You are using the SSH remote URL, not HTTPS:
git remote -v
If needed, switch the remote from HTTPS to SSH:
git remote set-url origin [email protected]:username/repository.git
SSL certificate problem when cloning via HTTPS
If you get an SSL error, make sure the ca-certificates package is installed:
sudo dnf install ca-certificates -y
sudo update-ca-trust
Do not disable SSL verification globally – that is a security risk. Fix the certificate chain instead.
Build from source fails with missing dependencies
If make fails during the source build, you are likely missing a development package. Check the error message for the missing header file and install the corresponding -devel package. Common ones:
sudo dnf install libcurl-devel expat-devel openssl-devel zlib-devel -y
Old Git version still showing after source install
If git --version still shows the old version after building from source, it means the system-packaged Git in /usr/bin is taking priority. Either:
- Remove the packaged Git:
sudo dnf remove git -y - Or make sure
/usr/local/bincomes before/usr/binin your PATH
After fixing, open a new shell or run hash -r to clear the shell’s command cache:
hash -r
git --version
Merge conflicts
When Git cannot automatically merge changes, you need to resolve conflicts manually. Open the conflicting files, look for the conflict markers (<<<<<<<, =======, >>>>>>>), edit the file to keep the correct code, then:
git add resolved-file.txt
git commit -m "Resolve merge conflict in resolved-file.txt"
Conclusion
You now have Git installed and configured on RHEL 10, Rocky Linux 10, or AlmaLinux 10. Whether you went with the repository package for stability or built from source for the latest features, your setup is ready for daily use. The SSH keys, aliases, and configuration covered here will save you time across every project you work on.
































































It works.
Thanks.
All the git files appear to be in my home directory. It would help to specify the directory where to install it, and/or how to move the files after install.