Git from a Linux shell
Installing and using Git on the command line in Linux gives administrators a lightweight way to track configuration, scripts and documentation over SSH. Git stores snapshots locally, so a shell session needs no desktop client.
On Australian estates, package choice follows the local market: RHEL and CentOS Stream are common in larger organisations, Ubuntu is widespread in smaller teams, and Fedora is popular for learning. A quick “no worries” in an operations chat may mean a check passed, but its output still needs recording.
Installing Git on Linux distributions
Check whether Git is already installed before adding packages:
command -v git
git --version
Use the package manager that matches the distribution:
# Fedora, RHEL 9+, CentOS Stream
sudo dnf install git
# Older RHEL or CentOS
sudo yum install git
# Debian or Ubuntu
sudo apt update && sudo apt install git
Administrators in Sydney, Melbourne and Canberra often support mixed estates, so read /etc/os-release before choosing a command. After installation, git --version confirms the result.
Setting your identity and defaults
Configure the name and email address that Git will record in commits:
git config --global user.name "Alex Morgan"
git config --global user.email "alex@example.com"
git config --global init.defaultBranch main
Check the active configuration with git config --list --show-origin. Global settings apply to every repository, while an organisation account can override an address using git config user.email "name@example.com". Commit identity is metadata rather than authentication, so it should match your hosting provider’s policy.
Creating and exploring a repository
Create a working directory and initialise the repository:
mkdir -p ~/projects/ops-tools
cd ~/projects/ops-tools
git init
Add the first file and inspect the working tree:
printf '%s\n' '# Operations tools' > README.md
git add README.md
git commit -m "Add project readme"
git status --short
Create a .gitignore before collecting more files. Exclude environment files, private keys, logs and generated archives because deleting a secret later does not remove it from Git history. Review git status --short before every commit so unrelated files remain outside the snapshot.
Branching and working with remotes
Create a topic branch for isolated work, then return to the main branch:
git switch -c feature/log-cleanup
git switch main
For collaboration, clone an existing repository with git clone git@github.com:example/ops-tools.git, or attach a remote in an existing checkout with git remote add origin git@github.com:example/ops-tools.git. Publish the current branch using git push -u origin main.
Operational documents fit naturally into this workflow. The guide at https://linuxtpoint.com/articles/2026/10/16/setting-up-a-logging-server-with-rsyslog-on-centos offers a practical rsyslog example that can be reviewed and versioned alongside authorisation and rollback steps.
Australian commit timestamps need care: daylight-saving changes in New South Wales, Victoria, South Australia and Tasmania can shift displayed local times, while Brisbane stays on AEST. Compare timestamps in UTC when coordinating across the country.
Reviewing history and fixing mistakes
Use history views to see where a branch came from:
git log --oneline --decorate --graph --all
git show HEAD
If a change should never have been staged, unstage it with git restore --staged path/to/file. To discard unstaged edits, use git restore path/to/file; both preserve earlier commits and are safer than an immediate hard reset.
When branches conflict, Git marks the affected paths. Run git status, edit each file to retain the correct content, stage the resolved files with git add path/to/file, and complete the merge with git commit.
For unusual hook or credential-helper failures, https://linuxtpoint.com/articles/2026/10/01/how-to-use-strace-to-debug-application-behavior can help trace Git behaviour before changing permissions or key ownership.
Git in everyday system administration
Git is particularly useful for versioned Nginx templates, firewall rules and deployment scripts. Validate changes on the target system, then stage only the intended files:
git diff -- nginx/site.conf
git diff --check
git add nginx/site.conf
git commit -m "Update site TLS settings"
Never commit passwords, private keys or exported firewall rules containing credentials. For WordPress estates, teams can pair version control with WordPress quality checks before accepting plugin or theme changes.
These commands cover the checks used most often during an administration review:
| Need | Command | Check |
|---|---|---|
| Working tree | git status --short |
Staged and unstaged paths |
| Review patch | git diff |
Exact content changes |
| Whitespace | git diff --check |
Trailing spaces and conflict marks |
| History | git log --oneline --decorate |
Concise commit sequence |
| Remote refs | git fetch --prune |
Deleted remote branches removed |
Use the working-tree and patch views before committing; use history and remote-reference views when reviewing a release. This habit leaves an auditable trail without copying production secrets into Git.
A repeatable daily workflow
After confirming a clean working tree, a compact daily loop keeps local and remote branches aligned:
git status --short
git pull --ff-only
git add path/to/file
git commit -m "Describe the change"
git push
For teams distributed across the country, keep commits small, use descriptive branch names and avoid rewriting shared history. Rebase an unpublished feature branch with git rebase main when integration is required, but let a colleague handle complex merges.
The next concrete step is to create a scratch repository under /tmp, make one commit and save git log --oneline output to /tmp/git-first-check.txt.