Git Essentials for Sysadmins: Commit, Branch, Share, Undo

Git looks intimidating because it has a lot of commands, but underneath it does one simple thing: it takes snapshots of a directory and remembers them in order. Each snapshot is a commit. A commit records what every tracked file looked like at that moment, who made it, when, why (the message), and which commit came before it. Chain those together and you get a timeline of your project you can read, compare, and go back to.

A useful picture is a save-game system. Every commit is a save point. You can look at any old save, start a side quest from one (a branch), and later fold the side quest back into the main story (a merge). Nothing you saved is ever overwritten by a new save; new saves are added on top.

Three places matter, and almost every confusing Git moment comes from mixing them up:

• Working tree: the files you see and edit in the directory.
• Staging area (also called the index): the set of changes you've picked for the next commit.
• Repository (the hidden .git directory): every commit ever made, plus labels such as branch names and tags that point at commits.

You edit in the working tree, choose changes with git add (staging), and record them with git commit (repository). git status tells you, at any moment, what sits in each place.

Let's make a repository for a small piece of server config. git init turns an ordinary directory into a repository by creating the hidden .git directory inside it. Nothing about your files changes; Git simply starts watching the directory. We'll name the first branch main, which is the modern default.

Before Git will record a commit it needs to know who is making it, because every commit carries an author name and email. You can set them for your whole account with --global (stored in ~/.gitconfig), or for just one repository by leaving --global off (stored in that repository's .git/config). On your own login, global is the convenient choice; on a shared account such as root on a team server, prefer per-repository so your name doesn't end up on everyone's commits.

Now create a file and watch how Git sees it. A brand-new file starts out untracked: Git notices it but won't include it in commits until you say so.

A branch sounds heavy, but in Git it is just a label that points at a commit and moves forward each time you commit on it. main is one label. Creating a branch makes a second label at the same commit; switching to it means new commits move that label and leave main where it was. That's why branches are cheap: Git doesn't copy any files to make one.

Teams use branches so an unfinished or unreviewed change never lands on main by accident. The usual loop is: branch, commit, review, merge.

To bring the fix into main, switch to main and merge the branch. You always merge into the branch you're on.

Some files should never be in history: build artifacts, logs, editor swap files, and above all secrets. A .gitignore file lists patterns Git should treat as invisible. Ignored files don't show up as untracked and aren't picked up by git add .. The .gitignore file itself is committed, so everyone who clones the repository gets the same rules.

So far everything has been local. Teams share work through a remote: another copy of the repository, usually on a server. A server copy is typically a bare repository: just the .git contents, with no working tree, because nobody edits files there directly. git clone copies a repository and remembers where it came from under the name origin.

It helps to picture this as a shared notebook in the office: you photocopy it (clone), write your pages at your desk (commit), then add your pages to the shared copy (push).

A tag is a permanent name for one commit, typically a release: v1.4.1. A lightweight tag is just a name. An annotated tag (-a) is a full object with its own message, tagger and date, and it's what release tooling expects. Tags behave differently from branches in one important way: git push does not send them unless you ask.

Sooner or later a bad commit lands. Git gives you two very different ways to undo it, and picking the wrong one on a shared branch causes real pain.

• `git revert <commit>` adds a new commit that applies the exact opposite of the bad one. History only grows. Everyone who already pulled just pulls again.
• `git reset --hard <commit>` moves the branch label back, so later commits drop out of the branch. That's fine for commits nobody else has seen, but once they're pushed, putting the reset on the server needs --force, and everyone else's copy suddenly disagrees with the server.

Think of a shared logbook: revert is writing a correction on a new line; reset is tearing the pages out after other people have copied them.

Reading Git is one thing; it sticks when your fingers have done it. Run this loop in the terminal and check the output at each step against what you learned above. It's the same sequence the LFCS Git labs grade: commit, branch, merge, ignore, tag, push and revert.