Git is the standard version control system for developers and sysadmins alike, and getting it running on Linux takes just a few minutes. This guide walks you through installation, basic configuration, and the everyday commands you'll actually use.
Publish date: 5/8/2026
If you've spent any time developing software, managing config files, or running your own servers, you've almost certainly run into Git. It's the version control system that most of the modern software world runs on, and for good reason. Git makes it easy to track changes, collaborate with others, and roll back mistakes without losing your mind.
Whether you're a developer pushing code to GitHub, a sysadmin versioning your server configs, or someone just getting started with Linux, learning Git is one of those things that pays off pretty quickly.
This guide will cover how to install Git on the most common Linux distributions, how to configure it for the first time, and how to use it day-to-day. No prior experience required.
Git is a distributed version control system originally created by Linus Torvalds in 2005 to manage the Linux kernel's source code. Instead of saving a single file that gets overwritten, Git keeps a full history of every change ever made to your project, who made it, and when.
What makes Git "distributed" is that every person working on a project has a complete copy of the entire history on their own machine. There's no single point of failure, and you can work offline just fine.
You might also hear Git mentioned alongside platforms like GitHub, GitLab, or Bitbucket. Those are hosting services built on top of Git, not Git itself. Git is the tool; those platforms are where you store and share your repositories remotely.
Git is available in the default package repositories of virtually every major Linux distribution, so installation is straightforward.
sudo apt update
sudo apt install git
sudo dnf install git
sudo pacman -S git
Once it's installed, verify it worked:
git --version
You should see something like git version 2.43.0. The exact version will vary depending on your distribution.
Before you start using Git, you need to tell it who you are. Git attaches your name and email address to every commit you make, so this matters even if you're only working locally.
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
You can also set your preferred text editor. By default, Git often falls back to Vim, which can be a surprise if you're not expecting it. If you'd rather use Nano:
git config --global core.editor nano
To check your current configuration at any time:
git config --list
These settings are stored in ~/.gitconfig in your home directory.
Before jumping into commands, it helps to understand a few key terms.
A repository (or "repo") is just a directory that Git is tracking. It contains your project files plus a hidden .git folder that stores all the version history.
A commit is a saved snapshot of your project at a specific point in time. Each commit has a unique ID, a message describing what changed, and metadata about who made it.
A branch is an independent line of development. You can create branches to work on features or fixes without touching the main codebase, then merge them back when ready.
The staging area (also called the index) is a middle step between your working files and a commit. You explicitly add files to the staging area before committing, which gives you fine-grained control over what goes into each snapshot.
To start tracking a project with Git, navigate to the project directory and run:
git init
This creates a .git folder and turns the directory into a Git repository. Nothing is committed yet; you've just initialized it.
If you want to download a copy of an existing project, use git clone:
git clone https://github.com/username/repository.git
This creates a new directory with the project name, downloads all the files, and pulls in the full commit history.
One of the most used commands you'll run is:
git status
It tells you which files have been modified, which are staged for the next commit, and which are untracked. Run it often, it's your sanity check.
Once you've made some changes, you need to stage them before committing. To stage a specific file:
git add filename.txt
To stage everything that's changed:
git add .
Then commit with a message:
git commit -m "Add initial configuration file"
Write commit messages that are brief but descriptive. Future you (and anyone else reading the history) will thank you.
To see a log of all commits:
git log
For a more compact view:
git log --oneline
This shows each commit on a single line with its short ID and message, which is a lot easier to scan through.
To create a new branch:
git branch feature-login
To switch to it:
git checkout feature-login
Or, combine both steps into one:
git checkout -b feature-login
When you're done with the feature and want to merge it back into your main branch:
git checkout main
git merge feature-login
To see all branches:
git branch
If you're working with a remote repository (say, on GitHub or a self-hosted GitLab instance), you'll need to push your local commits up and pull down changes from others.
First, add a remote if you haven't already:
git remote add origin https://github.com/username/repository.git
Push your commits:
git push origin main
Pull down changes:
git pull origin main
Git gives you several ways to backtrack.
To unstage a file you accidentally staged:
git restore --staged filename.txt
To discard uncommitted changes to a file and restore it to the last committed state:
git restore filename.txt
To undo the last commit but keep your changes staged:
git reset --soft HEAD~1
To undo the last commit and discard the changes entirely (use with care):
git reset --hard HEAD~1
Not everything in your project directory should be tracked. Log files, compiled binaries, environment files with secrets, and editor-specific folders are all things you'll typically want Git to ignore.
Create a .gitignore file in the root of your repository and list patterns for files and folders to exclude:
*.log
node_modules/
.env
__pycache__/
Git will then skip those files when staging and committing. GitHub maintains a collection of useful .gitignore templates for common languages and frameworks.
If you're frequently pushing to GitHub or GitLab, typing your password every time gets old fast. SSH key authentication solves this.
Generate a key pair if you don't already have one:
ssh-keygen -t ed25519 -C "[email protected]"
Then print your public key:
cat ~/.ssh/id_ed25519.pub
Copy the output and add it to your GitHub or GitLab account under Settings > SSH Keys. After that, use the SSH URL when cloning:
git clone [email protected]:username/repository.git
For a broader look at SSH and how it works on Linux, check out xTom's SSH guide.
Git itself doesn't require an internet connection or a third-party platform. You can use it entirely locally, or push to a server you control. If you want full ownership of your code and history, self-hosting GitLab is a solid option and it's more approachable to set up than you might expect.
Git is the version control software that runs on your local machine. GitHub is a cloud platform where you can host Git repositories online, collaborate with others, and manage projects. You can use Git without GitHub entirely, and there are several alternatives like GitLab and Gitea if you'd rather self-host.
Not necessarily, but in practice you'll almost always end up using it. Most projects you'll deploy via Docker are distributed as Git repositories, and versioning your configuration files with Git is widely considered a best practice for server management.
Absolutely, and it's a great habit. Tracking files like your Nginx configs, Docker Compose files, or /etc settings in a Git repo means you always have a history of what changed and can roll back if something breaks.
git pull and git fetch?git fetch downloads changes from the remote but doesn't apply them to your working branch. git pull does both; it fetches and then merges. Using git fetch first lets you review what's coming before integrating it.
To delete a local branch: git branch -d branch-name. To delete the remote branch as well: git push origin --delete branch-name.
No. Once something is committed to a Git repository and pushed to a remote, it's very difficult to fully remove. Never commit passwords, API keys, private keys, or other secrets. Use a .gitignore to exclude sensitive files and consider tools like git-secrets to catch accidental leaks.
Git is one of those tools that's worth investing time in early. Once the basic workflow clicks, version control starts to feel natural, and going back to working without it is genuinely uncomfortable.
Whether you're managing a single project or collaborating across a whole team, Git gives you a reliable record of your work and the freedom to experiment without fear.
Thanks for reading! If you're looking for reliable infrastructure to host your projects, xTom provides enterprise-grade dedicated servers and colocation services, along with IP transit and shared hosting options. V.PS offers scalable, production-ready NVMe-powered VPS hosting that's a great fit for anything from a personal Git server to a full GitLab instance. You can browse all available services here.
Ready to discuss your infrastructure needs? Contact our team to explore the right solution for your projects.