What Is Git? A Practical Guide to Version Control

Git is a distributed version control system that records changes as commits, lets you isolate work in branches, and helps you collaborate through remote repositories. It runs locally, so you can inspect history and return to an earlier version even when a hosting service is unavailable.

What Is Git, and What Problem Does It Solve?

I first understood Git properly after a configuration change went wrong and I needed to answer a simple question: what was different from yesterday? Looking at the current files was not enough. I needed the exact change, its author, its time, and a safe way back.

Git is a distributed version control system. It records changes to files in a local repository, so you can inspect history, create parallel lines of work, and return to a known commit without depending on an online service.

Git was created for the development of the Linux kernel. I use it for application code, Bash automation such as What Is Bash Scripting? A Guide to Linux Automation, infrastructure definitions, and documentation.

GitHub, GitLab, and Bitbucket are not Git itself. They host Git repositories remotely and add features such as code review, access control, issues, and CI/CD. Git can work perfectly well on your own machine or on a server you control.

What information does Git store?

• The contents of files at a particular point in time
• The author and timestamp associated with a commit
• The commit message and parent-commit relationships
• References such as branches and tags
• Object identities that help Git verify content integrity

Git is not just a directory full of old file copies. Commits are connected objects, while a branch is a movable reference pointing to a commit. That model explains why branches are cheap to create and why a repository can show exactly how one version led to another.

mkdir my-project
cd my-project
git init
git add .
git commit -m "Initial commit"

The first commit gives the repository a useful starting point. Write a message you will understand six months from now, not just update. Small habit. Large payoff.

What to do – Create a repository with git init, then make an initial commit that describes what you recorded.

The Three Places Your Changes Pass Through

When I explain Git to someone on a hosting shift, I start with three places: the working tree, the staging area, and the repository. Once these are separate in your head, most daily Git commands become less mysterious.

Suppose you edit two files but stage only one with git add. The next commit contains only the staged file. That separation lets you keep unrelated work out of the same commit.

git status
git add nginx.conf
git diff --cached
git commit -m "Update Nginx proxy settings"

git diff --cached shows what is already staged. Read it before committing. I once found an unrelated local configuration file there just in time. It was not a password, but it did not belong in the Nginx change either.

What to do – Read git diff --cached immediately before git commit so the wrong file does not enter the repository.

Commits, Branches, Merge, and Rebase

A commit records a project state along with metadata and its parent relationship. A useful message identifies the work in a short, searchable form. fix: increase SMTP timeout to 30 seconds tells me much more than update.

A branch is a movable reference to a commit. It gives you a separate line of work for a feature, a fix, or a risky configuration change, without changing the main branch directly.

git switch -c feature/healthcheck
git add .
git commit -m "Add HTTP healthcheck"
git switch main
git merge --no-ff feature/healthcheck

git switch -c creates a branch and moves you to it. Older Git versions can use git checkout -b for the same task. The --no-ff option keeps a visible merge commit; leave it out if your team prefers fast-forward merges.

Merge and rebase do different things

merge combines histories and can create a merge commit. rebase recreates commits on top of another base, which gives local work a different ancestry. I use rebase for unpublished work, but I do not casually rebase a branch other people have already pulled.

What to do – Do not rewrite a shared branch with git push --force unless the team has explicitly agreed on the recovery plan.

A Practical Git Session

I do not try to memorize Git as a list of unrelated commands. My usual sequence is simple: see the state, inspect the change, stage deliberately, inspect again, and commit.

git clone ssh://git@example.com/application.git
cd application
git status
git switch -c fix/login-timeout
vim config/app.conf
git diff
git add config/app.conf
git diff --cached
git commit -m "Fix login timeout configuration"
git log --oneline --decorate -5

git clone copies a remote repository and its history to your machine. git diff shows unstaged changes, while git log --oneline displays a compact history.

Stage parts of a file and undo carefully

git add -p lets you select individual hunks. That is useful when one file contains two unrelated edits. I have used it after a long night shift when a quick fix had accidentally brought a second, unfinished change along with it.

git add -p
git restore --staged config/app.conf
git restore config/app.conf

git restore --staged removes the file from the staging area but keeps the working-tree edits. The second command discards uncommitted working-tree changes. It is not a preview. Check the file first.

What to do – Run git status and inspect git diff before using a restore command on work you may need.

Remotes, Fetch, Pull, and Push

A local repository works by itself. For collaboration, you normally configure a remote, often named origin. git fetch downloads remote references and commit information without changing your working tree. git pull normally fetches and then performs a merge or rebase, depending on your configuration and options.

git remote -v
git fetch origin
git log --oneline HEAD..origin/main
git switch main
git pull --ff-only origin main
git push -u origin feature/healthcheck

The HEAD..origin/main range shows commits reachable from the remote-tracking branch but not from your current commit. If the remote branch has not been fetched or does not exist, that command will not tell you anything useful, so check git fetch and the branch name first.

git pull --ff-only refuses to create an automatic merge when the histories have diverged. I prefer that behavior on servers because it stops instead of quietly inventing a merge commit.

An SSH remote can look like git@example.com:team/app.git. With HTTPS, use an access token or credential method supported by the hosting provider rather than a password. Private keys, API tokens, and .env files do not belong in the repository.

What does .gitignore do?

.gitignore defines patterns for files Git should not start tracking. Common examples include vendor/, node_modules/, and .env. Adding an already tracked file to .gitignore does not remove it from history; use git rm --cached to stop tracking the current copy, then deal with any secret that may already exist in older commits.

What to do – Fetch before pushing, inspect the remote difference, and choose merge or rebase deliberately.

Git Is Not a Backup System

Git preserves the history of files inside the repository. GitHub and GitLab provide hosting and collaboration around those repositories. Neither fact means that Git automatically backs up your database, uploaded images, user files, or production server state.

Schema migration files from a MySQL setup such as How to Install and Secure MySQL on a VPS belong in Git. The live MySQL data needs its own backup and restore procedure.

A secret deleted from the latest version may still be present in an older commit. Revoke or rotate a key that entered the history. Deleting the file later is not enough.

Infrastructure code benefits from the same review process. Cloud-Init definitions from What Is Cloud-Init? Automate VPS Provisioning and Compose files from How to Install Docker on a VPS and Run Your First Container can be reviewed, branched, and rolled back. The data running inside those services still needs separate protection.

What to do – Keep repository copies in separate locations, and test restoration of production data instead of trusting that a successful backup command means the backup is usable.

Resolving a Git Conflict Without Guessing

A conflict appears when Git cannot combine two changes automatically. Usually, two branches have changed the same lines. Git does not know which behavior you intended, so it marks the file and stops.

<<<<<<< HEAD
proxy_read_timeout 30s;
=======
proxy_read_timeout 60s;
>>>>>>> feature/timeout

Choose the correct setting and remove every conflict marker. Then test the resulting file before staging it.

git status
vim nginx.conf
nginx -t
git add nginx.conf
git commit -m "Resolve Nginx timeout conflict"

nginx -t checks Nginx syntax, but syntax is only the first check. Test application behavior too. For a Docker configuration, run the validation command appropriate for the Compose version and project. For an application, run its tests.

When several files conflict, git status shows what remains. If the merge no longer makes sense, use git merge --abort. During a rebase, use git rebase --abort.

I keep a retired Debian T480 for changes that might break a service. It is not a perfect production replica, but it has stopped me from treating a clean-looking merge as proof that the service will start. That proof comes from testing.

Git Mistakes I Still Watch For

Adding everything with git add .: Temporary files and local configuration can enter the commit. Check git status, and name files explicitly when that is safer.

Using commit history as a password vault: Removing a secret from the current file does not remove older copies. Rotate the credential and plan any history rewrite carefully.

Force-pushing casually: git push --force-with-lease protects against some unexpected remote changes, but it still rewrites history. It is not harmless.

Merging without testing: A tidy history does not prove that the service works. Run configuration checks, application tests, and a staging deployment when the change deserves one.

Using Git instead of backups: One repository copy is not a recovery plan if the account disappears or access is lost. Keep an independent copy and verify that it can be restored.

Git earns its place in my daily work because it makes change traceable. Small, clear commits shorten investigations; vague commits turn a simple rollback into archaeology.

What to do – Before closing the terminal, confirm the branch, read the staged diff, run the relevant tests, and know where the next restorable copy lives.

Check These Before You Commit or Push

• Run git status and confirm the current branch.
• Inspect unstaged changes with git diff.
• Stage only the files or hunks belonging to this change.
• Read git diff –cached before committing.
• Write a commit message that describes the actual work.
• Run the relevant application and configuration tests.
• Fetch remote changes and avoid force-pushing shared branches.

Frequently Asked Questions

Sources

• Git Reference Documentation — git-scm.com
• Pro Git Book — git-scm.com
• Git Documentation – gitignore — git-scm.com
• Git Documentation – git push — git-scm.com