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 sudo privileges (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:

  1. Your SSH key is added to the agent: ssh-add -l
  2. The public key is uploaded to GitHub/GitLab
  3. 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/bin comes before /usr/bin in 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.

3 COMMENTS

  1. 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.

LEAVE A REPLY

Please enter your comment!
Please enter your name here