Learn Git Commands Fast and Easily

Git may be confusing to learn at first, but once you master a few essential commands, it will greatly speed up your development workflow. If you are new to Ubuntu and just getting started with Git or managing multiple servers on Rocky Linux using Git or working in any type of DevOps pipeline, Git is the tool that you will use every single day. This guide covers the most important Git commands for linux developers which includes real terminal examples, troubleshooting fixes, and a cheat sheet that you can keep open while you work.

Examples

Git is a free, open-source distributed version control system that tracks changes in your code over time. It was created by Linus Torvalds in 2005 to manage the Linux kernel source code. Instead of saving one single file and overwriting it each time, Git stores a full history of every change ever made to your project.

The key idea is that your entire project history lives locally on your machine. You do not need internet access to commit, branch, or roll back changes. You only need a connection when syncing with a remote server like GitHub or GitLab.

Every developer on a team can work on their own copy of the code, and Git handles merging everything back together. This makes it the backbone of modern software development, DevOps pipelines, and even Linux system administration scripts.

Most Linux distributions include Git in their default repositories. Here is how to install and verify it on the two most common enterprise Linux platforms.

On Ubuntu 24.04 (apt)

On Rocky Linux 9 / CentOS Stream 10 / RHEL 9 (dnf)

After installation, verify the version installed on your system:

Every Git command follows the same basic structure. Once you understand this pattern, reading any Git command becomes straightforward.

Where:

• git is the program itself
• [command] is what you want Git to do, like commit, push, or branch
• [options] are optional flags that change how the command behaves, like --global or -m
• [arguments] are the targets the command acts on, like a file name or branch name

For example: git commit -m "initial commit" uses the commit command, the -m option to supply a message inline, and the message string as the argument.

The table below lists the most used Git commands grouped by category. Use this as your quick-reference cheat sheet for Linux development and DevOps work.

Before you run any Git command on a new Linux machine, you need to configure your identity. Git uses this information to label every commit you make. Run these two commands once globally and Git will remember them across all projects.

Starting a new project from scratch on your Linux machine involves three steps: initialize the repo, stage your files, and make the first commit. This is the core loop you will repeat hundreds of times as a developer.

Most older tutorials use git checkout to switch and create branches. Since Git 2.23, the recommended approach is to use git switch for branches and git restore for files. Both old and new forms work, but the modern commands are clearer about their intent. Here is a side-by-side comparison:

Most real-world work starts by cloning an existing project. After cloning, Git automatically sets up the remote connection called origin. You can verify this and add extra remotes if needed.

This is one of the most common points of confusion for beginners. git fetch downloads remote changes but does not touch your working files. git pull does a fetch and then immediately merges those changes into your current branch. Use git fetch when you want to review what changed before merging.

The git log command shows the full commit history of your project. The default output is verbose, so most developers use flags to condense it. The combination below gives you a clean visual graph of your branch history.

There are two safe ways to undo work in Git depending on what you need. Use git restore to discard unstaged local changes to a file. Use git revert to undo a past commit by creating a new commit that cancels it out. This keeps the project history clean, which matters in shared branches.

Sometimes you are mid-way through a task and need to switch branches fast without committing half-finished work. git stash saves your uncommitted changes to a temporary stack and gives you a clean working directory.

You can create shortcuts for Git commands you type constantly. These are stored in your ~/.gitconfig file and work across all projects on your Linux machine. For Linux sysadmins and DevOps engineers working in the terminal all day, aliases save real time. This topic is closely related to Linux Bash scripting and automation, where reusable commands are a core concept.

Now instead of typing git status you just type git st. Verify your aliases were saved:

Here is a complete end-to-end Git workflow that mirrors what real teams do in production. This covers creating a feature branch, committing work, pushing to the remote, tagging a release, and rolling back if something goes wrong. If you are building DevOps skills, this workflow connects directly to what is covered in our Linux DevOps career guide.

A .gitignore file tells Git which files and folders to never track. This is important for keeping things like log files, compiled binaries, environment variables, and editor config files out of your repository. You should create this file at the root of every project before the first commit.

Create the .gitignore file using your text editor and add one pattern per line:

Add the following lines inside the file, then save and exit:

Now stage and commit the file:

Tags mark important points in project history, like version releases. If a release breaks something in production, you can roll back to the last stable tag using git reset or by checking out the tagged commit on a new branch.

Rebasing replays your branch commits on top of another branch, giving you a clean straight-line history instead of a tangled merge graph. Senior developers use rebase before opening pull requests so reviewers see a clean commit trail. This is different from merge, which creates an extra merge commit. The golden rule is: never rebase commits that have already been pushed to a shared branch.

To do an interactive rebase and clean up the last 3 commits before pushing (squash, rename, or drop them):

Cherry-pick lets you take a single commit from any branch and apply it to your current branch without merging the whole branch. This is very useful for hotfixes: if a bug fix was committed to a feature branch and you need it on main right now, you cherry-pick just that one commit.

The reflog is Git's secret safety net. It records every single move your HEAD pointer has made, even operations like rebase, reset, and deleted branches that are no longer visible in normal git log. If you accidentally reset too far or deleted a branch you needed, git reflog shows you the full hidden history so you can get back to any previous state.

To restore a lost commit or recover a deleted branch, use the hash from reflog output:

There are three levels of git reset and understanding the difference between them is important. All three move the branch pointer back to a previous commit, but they handle your working files differently. Only use reset on commits that have not been pushed to a shared branch.

git blame shows you the author, commit hash, and timestamp for every single line in a file. When something is broken and you need to know who wrote that specific line and in which commit, this is the command you reach for. It is also useful for understanding why a decision was made by checking the commit message tied to that line.

To blame a specific range of lines only, use the -L flag:

git bisect uses binary search through your commit history to find the exact commit that introduced a bug. Instead of checking commits one by one, Git cuts the search range in half each time you mark a commit as good or bad. For a project with hundreds of commits, this can narrow down a broken commit in just 7 or 8 steps. This is a command that separates junior from senior developers because most beginners never learn it, but it saves enormous time during production debugging.

Git now checks out a commit in the middle. Test your code, then tell Git whether this commit is good or bad. Keep repeating until Git identifies the exact culprit:

Most Git errors are easy to fix once you know what they mean. Below are the most common ones you will hit on Ubuntu and Rocky Linux, with exact commands to solve each one.

Error 1: fatal: not a git repository

This means you ran a Git command outside a Git project folder. Either initialize a new repo or navigate to your existing project directory.

Error 2: You are in detached HEAD state

This happens when you check out a commit hash directly instead of a branch. Your changes will not be saved to any branch. To get back to a safe state, create a new branch from here or return to main.

Error 3: Merge conflict in file.txt

A conflict happens when two branches changed the same part of a file. Git marks the conflict areas in the file with angle brackets. Open the file, remove the conflict markers, keep the version you want, then stage and commit.

Error 4: Permission denied (publickey) when pushing

This error means your SSH key is not set up or not loaded. On Ubuntu and Rocky Linux, generate a new SSH key and add it to your GitHub or GitLab account settings.

Copy the output of that last command and paste it into your GitHub SSH keys settings page. Then test the connection:

Git is not just for software developers. Linux system administrators use Git to version-control configuration files, shell scripts, Ansible playbooks, and Dockerfiles. When something breaks in production, Git history tells you exactly what changed and when, which cuts down debugging time significantly.

For DevOps engineers, Git is the starting point of every CI/CD pipeline. Code cannot be built, tested, or deployed automatically without a Git repository at the foundation. Tools like Jenkins, GitHub Actions, and GitLab CI all trigger on Git events like commits and tags. If you are working toward a DevOps role, understanding Git commands deeply is listed as a required skill in virtually every job description. Our Linux shell scripting interview questions guide also highlights Git knowledge as a common topic in technical interviews.

Git also protects you from yourself. Every commit is a restore point. Even if you accidentally delete files or break something with a bad edit, you can always go back. On a Linux server managing scripts and configs, that safety net is genuinely valuable. When combined with tools like cron for scheduling, which you can explore in our cron command guide, Git-controlled scripts become much easier to maintain over time. Mastering essential git commands for Linux developers is now a core requirement listed in sysadmin and DevOps job descriptions worldwide.