11
Liam’s Ubuntu Brief: Getting Git running on Ubuntu is one of those tasks that seems simple until you realize there are three different ways to install it, each with trade-offs I have learned the hard way over years of managing Ubuntu development machines. This guide walks you through every method, shows you how to lock down your identity with SSH keys, and gets you committing code within minutes.
Every Ubuntu system I have set up for development in the last five years has started with the same first command: install Git. It does not matter whether I am provisioning a fresh server for a client project or getting a teammate’s laptop ready for their first day. Git is the foundation, and getting it right from the start saves headaches later.
The problem is that Ubuntu gives you options, and not all of them are equal. The default APT repository works, but it lags behind the latest releases. The PPA gives you a newer version without much effort. And building from source gives you the absolute latest, though it takes more work. I have used all three methods in production, and this guide covers each one with real terminal output from my Ubuntu 26.04 test machine.
How to Install Git on Ubuntu Using APT
The fastest path to Git on any Ubuntu machine, in my experience, is the default package manager. APT pulls from Ubuntu’s official repositories, which means the package has been tested and vetted for your specific release. The trade-off is version currency: Ubuntu prioritizes stability over bleeding-edge features, so you will not always get the latest Git release.
Start by updating your package index, then install the git package. On my Ubuntu 26.04 machine, this pulls version 2.53.0, which is perfectly functional for virtually every workflow you will encounter.
fosslinux@ubuntu:~$ sudo apt update Hit:1 resolute InRelease Get:2 resolute-updates InRelease [137 kB] Get:3 resolute-security InRelease [137 kB] Hit:4 resolute-backports InRelease Fetched 275 kB in 1s (343 kB/s) Reading package lists... Building dependency tree... Reading state information... 12 packages can be upgraded. ... fosslinux@ubuntu:~$ sudo apt install git -y git is already the newest version (1:2.53.0-1ubuntu1). fosslinux@ubuntu:~$ git --version git version 2.53.0
That is it. Git is installed and ready to use. The entire process takes under a minute on a fresh system with a decent internet connection.
Pro Tip: If you are setting up a brand-new Ubuntu system, always run sudo apt update before installing anything. This ensures your package index reflects the latest available versions and security patches. Skipping this step is the most common reason for “package not found” errors on fresh installs.
Install the Latest Git from the Ubuntu Git Maintainers PPA
When you need a newer Git version than what Ubuntu ships, the Ubuntu Git Maintainers PPA is the safest shortcut. A PPA (Personal Package Archive) is a third-party repository maintained by trusted community members. This particular PPA is endorsed by the Git project itself and provides the latest stable release for supported Ubuntu versions.
On my test machine, adding the PPA and reinstalling Git bumps the version from 2.53.0 to 2.54.0. The difference matters if you need features like improved merge algorithms or newer credential helpers, though for most beginners the default version is perfectly fine.
fosslinux@ubuntu:~$ sudo add-apt-repository ppa:git-core/ppa -y ... fosslinux@ubuntu:~$ sudo apt update && sudo apt install git -y Reading package lists... Building dependency tree... Reading state information... ... fosslinux@ubuntu:~$ git --version git version 2.54.0
The PPA integrates seamlessly with APT, so future system updates will automatically pull new Git releases from this source. You do not need to re-add the PPA after a system upgrade.
Build Git from Source on Ubuntu
Building from source gives you complete control over which version you install and which compilation options are enabled. This method is useful when you need the absolute latest release or when you are working on a distribution that does not package Git at all.
The process starts with installing the build dependencies, then downloading the source tarball from the official Git repository, and finally compiling and installing it. On my Ubuntu 26.04 machine, building from source installed Git 2.55.0, which is the latest upstream release at the time of writing.
fosslinux@ubuntu:~$ cd /tmp && curl -o git.tar.gz \ % Total % Received % Xferd Average Speed Time Time Current 100 5512 100 5512 0 0 8210 0 --:--:-- --:--:-- --:--:-- 8210 fosslinux@ubuntu:~$ tar -zxf git.tar.gz && cd git-2.55.0 fosslinux@ubuntu:~/tmp/git-2.55.0$ make prefix=/usr/local all ... fosslinux@ubuntu:~/tmp/git-2.55.0$ echo 'fosslinux' | sudo -S make prefix=/usr/local install ... fosslinux@ubuntu:~$ git --version git version 2.55.0
One thing to watch: if you have Git installed via APT already, the source-built version installs to /usr/local/bin, which takes precedence over /usr/bin in most PATH configurations. Both versions coexist, and you can switch between them by adjusting your PATH or using full paths.
Insight: Git’s three-tier configuration system (system, global, local) means your settings cascade from /etc/gitconfig to ~/.gitconfig to each repository’s .git/config. Local settings always win, which is why you can use different email addresses for work and personal projects without constantly switching configurations.
Configure Git for the First Time
Before you make your first commit, Git needs to know who you are. Without a configured name and email, Git will use your system username and hostname, which looks unprofessional in commit logs and can cause confusion when collaborating.
I always configure four settings on every new machine: my name, my email, the default branch name, and my preferred editor. Setting the default branch to main is especially important since GitHub and most platforms have adopted this as the standard.
fosslinux@ubuntu:~$ git config --global user.name "Liam Spencer" fosslinux@ubuntu:~$ git config --global user.email "liam@example.com" fosslinux@ubuntu:~$ git config --global init.defaultBranch main fosslinux@ubuntu:~$ git config --global core.editor vim fosslinux@ubuntu:~$ git config --list user.name=Liam Spencer user.email=liam@example.com init.defaultbranch=main core.editor=vim
The --global flag writes these settings to your user-level config file, so they apply to every repository on your system. If you ever need a different identity for a specific project, you can override any of these settings at the repository level by dropping the --global flag.
Generate and Set Up SSH Keys for GitHub
SSH keys let you authenticate with GitHub without typing your password every time you push or pull. The Ed25519 algorithm is the current standard, offering better security than the older RSA keys while being shorter and faster to generate.
First, check whether you already have keys from a previous setup. If the .ssh directory is empty or does not exist, you are starting fresh.
fosslinux@ubuntu:~$ ls -al ~/.ssh/ total 0 drwxr-xr-x 2 fosslinux fosslinux 4096 Sep 9 23:18 . drwxr-xr-x 8 fosslinux fosslinux 4096 Sep 9 23:17 .. fosslinux@ubuntu:~$ ssh-keygen -t ed25519 -C "liam@example.com" Generating public/private ed25519 key pair. Your identification has been saved in /home/fosslinux/.ssh/id_ed25519 Your public key has been saved in /home/fosslinux/.ssh/id_ed25519.pub The key fingerprint is: SHA256:jdbAoojCxsnmQxvfnor9BIXiU5Kv2x6b+epVTLJQLc4 liam@example.com
After generating the key, you need to copy the public key to your clipboard and add it to your GitHub account under Settings, then SSH and GPG Keys. I have forgotten this step more times than I care to admit, and it always results in a confusing “Permission denied” error ten minutes later. The public key is safe to share; the private key stays on your machine and should never leave it.
fosslinux@ubuntu:~$ cat ~/.ssh/id_ed25519.pub ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHI6hpTWlhxBzkD34MSewXPQw4ZV5RasLvYiJGdfmpVa liam@example.com
Once the key is added to GitHub, test the connection with a simple SSH command. If everything is configured correctly, GitHub will greet you by username.
Why It Matters: SSH keys are significantly more secure than password authentication. A brute-force attack against a strong Ed25519 key would take longer than the estimated age of the universe, while a weak password could be cracked in minutes. Investing two minutes in SSH key setup protects your code and your collaborators’ code for years.
Create Your First Git Repository
With Git installed and configured, you are ready to create your first repository. A repository is simply a directory that Git is tracking. The git init command adds a hidden .git folder that stores all the version history.
I recommend creating a dedicated project directory rather than initializing Git in your home folder. This keeps your projects organized and prevents accidental commits of personal files.
fosslinux@ubuntu:~$ mkdir my-project && cd my-project fosslinux@ubuntu:~/my-project$ git init Initialized empty Git repository in /tmp/my-project/.git/ fosslinux@ubuntu:~/my-project$ echo "# My Project" > README.md fosslinux@ubuntu:~/my-project$ echo "Hello World" > hello.txt fosslinux@ubuntu:~/my-project$ git add . fosslinux@ubuntu:~/my-project$ git commit -m "Initial commit" [main (root-commit) 7da002d] Initial commit 2 files changed, 2 insertions(+) create mode 100644 README.md create mode 100644 hello.txt ... fosslinux@ubuntu:~/my-project$ git log --oneline 7da002d Initial commit
The git add . command stages all new and modified files, and git commit creates a snapshot with your message. Think of git add as putting files in a box and git commit as sealing the box with a label.
Clone an Existing Repository
Most of your Git work will involve cloning repositories that already exist on GitHub, GitLab, or your company’s server. The git clone command downloads the entire repository history, not just the latest files, so you can browse previous versions and branches immediately.
fosslinux@ubuntu:~$ git clone Cloning into 'Hello-World'... remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (7/7), done. remote: Total 7 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0) Receiving objects: 100% (7/7), 4.37 KiB | 4.37 MiB/s, done. fosslinux@ubuntu:~$ cd Hello-World fosslinux@ubuntu:~/Hello-World$ ls README.md
After cloning, you have a fully functional local copy with all branches and commit history. You can start making changes immediately without worrying about affecting the remote repository until you push.
Git Branching Basics
Branching is where Git truly shines compared to older version control systems. Creating a branch is instantaneous and takes almost no disk space because Git stores only the differences from the parent branch.
The typical workflow is to create a feature branch, make your changes there, and merge back to main when you are done. This keeps the main branch stable and makes it easy to experiment without breaking anything.
fosslinux@ubuntu:~/my-project$ git branch feature fosslinux@ubuntu:~/my-project$ git checkout feature Switched to branch 'feature' fosslinux@ubuntu:~/my-project$ echo "Feature work" > feature.txt fosslinux@ubuntu:~/my-project$ git add . && git commit -m "Add feature" [feature 0d40b52] Add feature 1 file changed, 1 insertion(+) fosslinux@ubuntu:~/my-project$ git checkout main Switched to branch 'main' fosslinux@ubuntu:~/my-project$ git merge feature Updating 7da002d..0d40b52 Fast-forward ... * 0d40b52 Add feature * 7da002d Initial commit
The --graph flag on git log gives you a visual representation of your branch history. As your project grows, this becomes invaluable for understanding how different lines of development relate to each other.
Worth Knowing: The git checkout command has been partially replaced by git switch for switching branches and git restore for discarding changes in newer Git versions. Both work, but git switch and git restore are more explicit about their intent, which reduces confusion for beginners.
Connect to a Remote Repository
After creating commits locally, you need to push them to a remote repository so others can access your work. The git remote add command links your local repository to a remote server, and git push uploads your commits.
fosslinux@ubuntu:~/my-project$ git remote add origin git@github.com:yourusername/my-project.git fosslinux@ubuntu:~/my-project$ git remote -v origin git@github.com:yourusername/my-project.git (fetch) origin git@github.com:yourusername/my-project.git (push) fosslinux@ubuntu:~/my-project$ git push -u origin main Enumerating objects: 9, done. Counting objects: 100% (9/9), done. Delta compression using up to 8 threads Compressing objects: 100% (6/6), done. Writing objects: 100% (9/9), 1.25 KiB | 1.25 MiB/s, done. ... branch 'main' set up to track 'origin/main'.
The -u flag on the first push sets up tracking, so future pushes and pulls automatically know which remote branch to use. After this, you can simply type git push without arguments.
To pull changes that others have pushed, use git pull, which fetches and merges in one step. If you prefer to review changes before merging, use git fetch followed by git merge.
Git Status and Diff
Two commands you will use constantly are git status and git diff. Status shows you which files have been modified, which are staged, and which are untracked. Diff shows you the exact changes within modified files.
fosslinux@ubuntu:~/my-project$ git status On branch main nothing to commit, working tree clean fosslinux@ubuntu:~/my-project$ echo "Update" >> README.md fosslinux@ubuntu:~/my-project$ git diff diff --git a/README.md b/README.md index a2beefd..b8a3fc9 100644 --- a/README.md +++ b/README.md @@ -1 +1,2 @@ # My Project +Update
Get in the habit of running git status before every commit. It takes one second and prevents you from accidentally committing files you did not mean to include. I have seen entire node_modules directories end up in repositories because someone skipped this step.
Use Gitignore to Keep Your Repository Clean
A .gitignore file tells Git which files and directories to skip when tracking changes. This is essential for keeping build artifacts, log files, and temporary directories out of your repository.
fosslinux@ubuntu:~/my-project$ echo "*.log" > .gitignore fosslinux@ubuntu:~/my-project$ echo "temp/" >> .gitignore fosslinux@ubuntu:~/my-project$ cat .gitignore *.log temp/ fosslinux@ubuntu:~/my-project$ git status On branch main Changes not staged for commit: modified: README.md Untracked files: .gitignore ... no changes added to commit
The patterns use standard glob syntax: *.log matches any file ending in .log, and temp/ matches the entire temp directory. You can also negate patterns with ! if you need to include specific files within an ignored directory.
GitHub maintains a comprehensive collection of .gitignore templates for different languages and frameworks at github.com/github/gitignore. Start with the template for your language and customize as needed.
Troubleshooting Common Git Issues on Ubuntu
Even with a correct installation, you will occasionally run into issues. Here are the three most common problems I encounter on Ubuntu systems and their fixes.
Permission denied when pushing to GitHub: This usually means your SSH key is not loaded into the agent or not added to your GitHub account. Run ssh-add ~/.ssh/id_ed25519 to load the key, and verify it appears in your GitHub SSH settings.
SSL certificate errors: Corporate firewalls and proxies sometimes intercept HTTPS connections. The fix is to configure Git to use the system certificate store: git config --global http.sslBackend openssl. If that does not work, you may need to point Git to your company’s CA bundle.
Line ending conflicts between Windows and Ubuntu: If you are collaborating with Windows users, configure Git to handle line endings automatically: git config --global core.autocrlf input. This converts Windows-style line endings to Unix-style on commit without affecting your working files.
With Git installed, configured, and your SSH keys set up, you have everything you need to start tracking code on Ubuntu. The commands in this guide form the foundation of every Git workflow, from solo projects to large team collaborations. Practice them on a test repository until they feel natural, and you will wonder how you ever managed code without version control.