Setting Up a Git Repository on elementary OS: A Practical Walkthrough
elementary OS has matured into a pleasant desktop for everyday computing, and a growing number of developers across Australia treat it as their primary coding environment. The Pantheon desktop stays out of the way, AppCenter handles application lifecycles cleanly, and the underlying Ubuntu base gives access to a deep pool of developer tools. Among those tools, Git stands out as the backbone of modern source code management. Whether you are maintaining a side project from a share house in Fitzroy or contributing to an open source library maintained by a team scattered between Adelaide and Perth, learning to spin up a reliable local repository on your elementary OS machine is the first real step.
Git is one of the most accessible pieces of software on Linux. It does not require a complicated server stack or graphical front end to be useful. A terminal, a clean directory, and a handful of well-known commands are usually enough to begin tracking changes to your code. With elementary OS 8 continuing to ship with solid terminal emulators, the barrier to entry is as low as it has ever been for Australian coders who prefer a polished, macOS-like aesthetic.
This guide assumes you are comfortable opening a terminal and navigating a filesystem, but you do not need to be a seasoned sysadmin. We will walk through installing Git, configuring your identity, creating your first local repository, linking it to a remote host, and setting up a workflow that scales from a solo hobby script to a small team collaboration. Each step builds on the last, so you can read end-to-end or jump to a section that matches where you are in your current setup.
By the end you will have a fully functional local repository on elementary OS, complete with SSH access, sensible default configuration, and the confidence to keep your commit history tidy. We will also look at hooks and backup strategies that protect your work from the kind of misfortune that has cost many an Australian freelancer a long weekend of recovery.
Installing and Configuring Git on elementary OS
Git ships in the elementary OS repositories, which makes installation straightforward. Open the terminal of your choice — the built-in Pantheon Terminal works well, though many developers in Sydney and Melbourne prefer GNOME Terminal or Tilix for split-pane workflows — and run the standard package command. A single sudo apt install git followed by your password is usually enough, though refreshing your package lists first with sudo apt update ensures you pull the latest stable release. Verify the install with git --version, which should return something like git version 2.42.x or newer depending on the Ubuntu base you are running on.
Configuration comes next. Git reads your name and email address from its config file and stamps them onto every commit you create. Use git config --global user.name "Your Name" and git config --global user.email "you@example.com". If you maintain separate identities for personal and work projects — a common situation for Australian contractors juggling multiple clients — override the global values inside a specific repository by omitting the --global flag.
It is also worth setting a default branch name and a default editor. Newer Git versions default to main, but you may want to set it explicitly with git config --global init.defaultBranch main. For the editor, core.editor lets you pick something like nano for beginners or vim for the more adventurous. A useful Australian touch: if you have ever hit a wall trying to push over a sluggish NBN upload during peak evening hours, enable extra compression on push with git config --global core.compression 9. It trades a little CPU for noticeably smaller transfers.
Creating Your First Local Repository
A Git repository is just a directory with a hidden .git folder that records every change you make. To start one, navigate in your terminal to the project folder you want to track — or create a new one with mkdir my-project && cd my-project — and run git init. Git responds with a line confirming it has initialised an empty repository in the current path. At this point nothing is tracked, but the plumbing is in place.
You can now add files the usual way, using your preferred editor or the Files application. When you are ready to record a snapshot, run git add filename to stage specific files, or git add . to stage everything in the directory. The staging area lets you curate exactly which changes belong together in a single commit, a control many Australian developers appreciate when separating cosmetic tweaks from functional fixes. Once you are happy with what is staged, git commit -m "A descriptive message" seals the deal.
A good commit message is short, written in the imperative mood, and explains the why rather than the what. Something like Add login form validation is more useful six months later than Updated stuff. Inspect what you have done with git log, adding --oneline for a condensed view or --graph --all --decorate for a visual representation of branches and merges. On elementary OS you can pipe this output into bat or delta for syntax highlighting, which makes long histories much easier to scan during an afternoon of code review.
Connecting to a Remote Host
A local repository is useful, but the real power of a distributed version control system comes from syncing with a remote. Common choices are hosted services like GitHub, GitLab, or Codeberg, but you can also host your own remote on a VPS, a Raspberry Pi at home, or another machine on your local network. For Australians concerned about data sovereignty or wanting to avoid monthly subscription fees billed in US dollars, self-hosting can be attractive, especially when paired with a local cloud region such as AWS Sydney or Azure Australia East.
The first thing you need is an SSH key pair. elementary OS ships with OpenSSH, so generating a key is a single command: ssh-keygen -t ed25519 -C "your-email@example.com". Accept the default location, and choose a passphrase if you want an extra layer of protection. The public key — the file ending in .pub — is what you upload to your remote host.
With the key in place, add the remote to your local repository with git remote add origin git@github.com:yourusername/your-repo.git, then verify with git remote -v to confirm both fetch and push URLs. Push your commits with git push -u origin main. The -u flag sets the upstream tracking reference, so subsequent pushes can be shortened to git push. If you are working from a shared apartment with patchy NBN, you may occasionally see the push fail mid-transfer, but Git is resilient: just rerun the command and it will resume from where it left off.
A Branching Workflow for Daily Use
Once the remote is connected, branches become your friend. A branch is a lightweight pointer to a commit, and creating one is almost instantaneous. The classic pattern is to make a new branch for each feature or fix, do the work there, push it to the remote, open a pull or merge request, and delete the branch once it has been merged. This keeps the main line of history clean and makes code review much easier, especially for distributed teams where reviewers might be on the other side of the country or the world.
To create and switch to a new branch in one step, run git checkout -b feature/my-new-thing. Make your changes, commit them as usual, and push with git push -u origin feature/my-new-thing. Your remote now has a copy of the branch that others can review. Australian open source maintainers often mention the convenience of this model during meetups, because it allows asynchronous collaboration across AEST and AEDT time zones without anyone needing to block on a colleague in another state.
When the work is ready, open a merge request on your host of choice. Most platforms will show a diff of your commits, allow reviewers to leave comments, and run any configured continuous integration checks. Once approved, merge into the main branch and delete the feature branch both locally and remotely. git fetch --all --prune cleans up stale references, and git branch -d feature/my-new-thing removes the local copy. Pulling is the other half of the dance: run git pull before you start each day, and resolve any conflicts with git status, manual editing, and git add. Most conflicts are trivial text overlaps that resolve in seconds once you understand the tool.
Hooks, Backups and Signed Commits
Git hooks are small scripts that run automatically when certain events happen, such as before a commit, after a push, or when a checkout finishes. They live in the .git/hooks directory of your repository and are written in whatever scripting language you prefer. A common use is a pre-commit hook that runs a linter or formatter, ensuring the code you commit follows the project's style. For Python projects, that might mean invoking ruff or black; for Markdown documentation, a spell checker that respects Australian spelling conventions by default.
Server-side hooks on a self-hosted bare repository are even more powerful. A post-receive hook can trigger a deployment script that pulls the latest code into a staging directory, restarts a systemd service, or sends a webhook to a chat channel. Many Australian agencies use this pattern to deploy small client websites straight from a push to their internal Git server, skipping the complexity of a full CI/CD pipeline. The simplicity is the appeal: a few lines of shell in a hook can replace an entire orchestration platform for a one-person team.
Backups deserve attention. Git is a distributed system, so every clone of a repository contains the full history. Pushing to a remote is itself a form of backup, but it is worth layering additional protection, especially if you work on a laptop and spend time in cafes or coworking spaces. Tools like borgbackup or restic can take regular snapshots of your home directory to an encrypted remote target. Finally, enable signed commits if your host supports it: GPG or SSH signing proves a commit really came from you, which buys meaningful cryptographic assurance for sensitive client work.
Your next step is short and concrete: open a terminal, create a new directory called git-practice, run git init inside it, add a single text file, commit it with a meaningful message, and inspect the result with git log.
