Using Git on Ubuntu for Everyday Version Control

Git is a version control system: it records changes to files so you can inspect what changed, retrieve an earlier version, and combine work from other people. A repository stores that history in a hidden .git directory, while each commit marks a particular set of changes. This local-first design makes Git useful on an Ubuntu desktop even without a GitHub or GitLab account.

For everyday users, Git can track configuration files, a personal website, a collection of scripts, or contributions to an open-source project. Its vocabulary sounds technical—working tree, staging area, branch, remote—but the basic routine is straightforward: edit a file, select the change, commit it with an explanation, and review the history when needed.

For Australian users, there are several practical angles. Git operates locally, so it remains available on a regional fixed-line or mobile connection that may be less consistent than an NBN service in Sydney or Melbourne. Shared repositories also need sensible time-zone and spelling conventions when contributors work in Brisbane, Perth, or other cities.

Install Git and check your setup

Ubuntu provides Git in its standard package repositories. Open Terminal and run:

sudo apt update
sudo apt install git
git --version

The first command refreshes the package index. The second installs Git and any required libraries, while the third confirms that the command is available and prints its version.

Use sudo for these system-level changes, not for ordinary Git operations inside your own project directory. Installing the package does not create a repository or upload anything online. A new project begins with git init, covered below.

A spare USB stick bought in Australia—JB Hi-Fi and Harvey Norman stock common storage options—can be used to create an Ubuntu live USB. Trying the distribution from that stick leaves the family desktop's existing system untouched, which provides a convenient way to explore Linux and practise version control before changing the installed operating system.

Configure Git with your identity

Git attaches an author name and email address to each commit. Set these once for your user account:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Replace the examples with your own details. These values are stored in ~/.gitconfig and included in commit metadata; they do not need to match the credentials used to sign in to a hosted service. If you prefer not to expose a personal address publicly, some providers offer account-specific no-reply email addresses.

Commit messages are another place where local habits matter. Australian English usually uses spellings such as “colour”, “organisation”, and “behaviour”, while many software projects follow American English. Choose the convention used by your collaborators and keep it consistent. Git records the message exactly as written and does not change its spelling.

A few global settings can simplify daily work:

git config --global init.defaultBranch main
git config --global pull.ff only
git config --global core.autocrlf input
git config --global --list

The first setting makes new repositories start on main. The second stops git pull from creating an automatic merge commit when a local branch has diverged from its remote counterpart. The third helps prevent Windows-style line endings from entering a shared Ubuntu project. The final command displays your current global configuration.

Create a repository and record changes

Start with a directory for the project. A repository can contain any type of files, including the scripts and notes used to build it:

mkdir -p ~/Projects/notes
cd ~/Projects/notes
git init
git status

Because of the earlier init.defaultBranch setting, a newly initialised repository uses main as its starting branch. git status reports that there are no commits yet, and it will continue to identify untracked files until they are added to the repository.

Create a file with an editor, then stage and commit it deliberately:

nano README.md
git add README.md
git commit -m "Document the project setup"
git log --oneline --decorate

git add moves a file into the staging area, which is the set of changes selected for the next commit. git commit records those staged changes with a message. The history command then displays the commit, its short identifier, and the branch currently pointing to it.

Before committing, it is useful to inspect exactly what has changed:

git diff
git diff --staged
git status

The first command compares the working tree with the staging area, while the second compares staged changes with the latest commit. After a successful commit, both differences should be empty. Staging selected files individually, rather than everything with git add ., reduces the chance of including an unwanted document or temporary file.

Create a .gitignore file for editor backups, operating-system metadata, and sensitive local files:

.DS_Store
Thumbs.db
*.swp
__pycache__/
.env

These patterns cover common macOS and Windows artefacts, Vim swap files, Python cache directories, and environment files. A password, private key, or API token should never enter a commit. Ignoring a file works only while it remains untracked: a secret already committed still needs to be revoked and removed from the history.

Work with branches, reviews and undo

Branches let you work on an idea without disturbing the version other people are using. Create a branch for the change, make the edits, and merge it when it is ready:

git switch -c feature/new-theme
git switch main
git merge feature/new-theme

The first command creates and enters feature/new-theme. The second returns to main, and the third incorporates the feature branch after its changes have been reviewed. If both branches altered the same lines, Git reports a conflict and marks the affected files so you can choose the correct content.

Diff and history tools provide the review itself:

git diff main...feature/new-theme
git log --graph --oneline --all
git show abc1234

The first command displays changes on the feature branch since it diverged from main. The graph command reveals how branches relate across the repository, and git show expands a particular commit.

Several commands handle common corrections:

git restore notes.txt
git restore --staged notes.txt
git revert abc1234

git restore discards unstaged edits to a file, while git restore --staged only removes it from the staging area. git revert creates a new commit that reverses an earlier change, which is safer for shared history than rewriting it. For an unpublished final commit, git commit --amend can correct its message or contents. Check git status before using any undo command, because some discard work immediately.

Commit timestamps depend on the computer's clock and time-zone settings. timedatectl status shows the current configuration. Brisbane observes Australian Eastern Standard Time throughout the year, whereas Sydney and Melbourne change their clocks for daylight saving. A commit still represents one fixed point in time, but readers in different zones may see different clock times for it in their logs.

Connect to remotes and build a durable routine

A remote repository is an online copy that supports collaboration and provides another place to store your work. GitHub and GitLab both offer private repositories on their free personal plans. Create an empty repository on the service, then connect the local directory:

git remote add origin https://github.com/username/project.git
git remote -v
git push -u origin main

Replace the sample account and project names with your actual ones. The remote command verifies the connection, and the push command uploads the local commits while recording main as the upstream branch. A remote is useful, but it is not essential: local commits and branches continue to work without an internet connection.

To obtain someone else's project, clone its repository:

git clone https://github.com/username/project.git

A normal clone copies the complete history into a new local directory. For services that request a personal access token, create one with the narrowest practical permissions and supply it when the terminal asks for HTTPS credentials. SSH keys are another option for repeated access. Do not place a token directly in a remote URL, where it may be exposed in configuration or terminal history.

These tools are widely used in community-driven software, where contributors can document changes and propose corrections through a shared history. Australian open-source maintainers may receive donations in Australian dollars through their project pages, and local Linux meetups in Melbourne or Brisbane provide face-to-face help for people learning the same distributed workflow.

A dependable Git routine is straightforward: check the status before committing, stage only intended files, review the difference, and record one coherent change at a time. Short, descriptive commits make later searches and reversions easier, while branches keep unfinished work away from a stable version. The practical takeaway is to treat each commit as a reliable checkpoint and each remote as an additional copy, preserving a clear history without leaving the project dependent on one laptop.