The Version Control Tool Everyone Uses and Many Misunderstand
Git is the version control system used by virtually every professional software development team — a tool that tracks changes to files over time, enables multiple developers to work on the same codebase simultaneously, and provides the ability to return to any previous state of a project. It’s also a tool that many developers use daily without fully understanding how it works, which produces the ‘I deleted something and now I can’t get it back’ and ‘I don’t know what state my repository is in’ experiences that characterise Git confusion.
Git’s learning curve is steep for a specific reason: its mental model requires understanding concepts (repository, commit, branch, merge, remote) that don’t have intuitive real-world analogies. Once these concepts are understood, the commands make sense; before they’re understood, the commands feel arbitrary. This guide focuses on the conceptual layer before the command layer.
The Core Concepts: Repository, Commit, and Branch
A repository (repo) is the container that holds a project’s files and the complete history of every change ever made to those files. The repository stores not just the current state of the files but every saved state throughout the project’s history, allowing travel to any previous state. Creating a repository with ‘git init’ turns a folder into a Git-tracked project; cloning a repository with ‘git clone [url]’ copies an existing repository (including its complete history) to the local machine.
A commit is a saved snapshot of the repository at a specific point in time — think of it as saving a version of the project that can be returned to later. Each commit has a message that describes what changed, who made the change, and when — building the history log that makes Git’s version control valuable. Commits are made by staging changes with ‘git add’ (selecting which changes to include in the next commit) and then saving the snapshot with ‘git commit -m [message]’. The staging step is Git’s way of allowing selective inclusion of changes rather than committing everything that’s changed simultaneously.
Branches: Working Without Breaking
A branch is an independent line of development that diverges from another branch (typically ‘main’ or ‘master’) at a specific point. Working on a branch allows developing a new feature or fixing a bug in isolation from the main codebase — other developers’ work continues on their branches, and the main branch remains stable. When the branch work is complete, it’s merged back into the main branch.
The branch commands that matter most: ‘git branch [name]’ creates a new branch; ‘git checkout [name]’ or ‘git switch [name]’ switches to that branch; ‘git checkout -b [name]’ creates and switches to a branch in one step. ‘git branch’ without arguments lists all local branches and marks the current one. ‘git merge [branch-name]’ while on the destination branch merges the specified branch into the current one. These five commands handle the majority of branching workflow in typical development.
Remotes: Working With GitHub and GitLab
A remote is a version of the repository hosted on a server rather than locally — GitHub, GitLab, and Bitbucket are the most widely used remote hosting services. The remote allows multiple developers to share code, provides a backup of the repository independent of any single developer’s machine, and is the foundation of collaborative development workflows.
The remote commands that matter: ‘git remote add origin [url]’ connects a local repository to a remote for the first time; ‘git push origin [branch]’ uploads local commits to the remote repository; ‘git pull origin [branch]’ downloads commits from the remote and merges them into the local branch; ‘git fetch origin’ downloads commits from the remote without merging (allowing inspection before merging with ‘git merge origin/[branch]’). The ‘origin’ name is a convention for the primary remote — it can be named anything, but ‘origin’ is standard and universally expected.
The Commands That Save You When Things Go Wrong
‘git status’ shows the current state of the working directory — which files have been modified, which are staged for the next commit, and which are untracked. This is the first command to run whenever the repository state is unclear; it provides the context needed to understand what happened and what to do next. ‘git log’ shows the commit history — the sequence of commits on the current branch, each with its hash, author, date, and message. ‘git log –oneline’ provides the same history in a compact format.
‘git stash’ temporarily saves uncommitted changes and reverts the working directory to the last commit — useful when you need to switch branches but have uncommitted work that isn’t ready to commit. ‘git stash pop’ restores the stashed changes. ‘git restore [file]’ or ‘git checkout — [file]’ reverts a specific file to its state at the last commit — the ‘I changed this file and want to undo all those changes’ command. ‘git reset –soft HEAD~1’ undoes the last commit while keeping the changes staged. These recovery commands transform Git from a scary tool that permanently alters state into a recoverable system where most mistakes can be corrected.