Git: An introduction to git and version control systems

Introduction

Every codebase that survives contact with time accumulates questions: Who changed this? When? Why did this function used to behave differently? Can we get back to last Tuesday's working state? These are not exotic edge cases - they are the daily reality of software development. Version control systems exist to answer these questions reliably and without drama.

Git has become the de facto answer to version control for most of the software industry. As of 2022, Stack Overflow's developer survey reported that over 93% of professional developers use Git, a number that has been climbing steadily for over a decade. But widespread adoption alone does not explain why Git is worth understanding deeply. What makes Git valuable - and occasionally confusing - is that it is built on a small set of powerful abstractions that compose in predictable ways. Learning the abstractions, not just the commands, is what turns Git from a source of occasional panic into a tool you can reason about and trust.

This article is structured as a genuine introduction: we start with why version control systems exist and what problems they solve, move through what makes Git's architecture distinctive, cover the essential commands with enough context to understand what they actually do, and finish with the practices that separate effective Git usage from cargo-culted habits. Whether you are new to Git or have been using it for years without fully understanding it, there is something here worth reading carefully.

The Problem Version Control Systems Solve

Before Git, before SVN, before even CVS, developers managed change through practices that seem absurd in retrospect but were rational responses to the tools available: copying folders with timestamps in the name (project_final, project_final_v2, project_final_ACTUALLY_FINAL), emailing zip files between collaborators, and maintaining mental models of who had the "current" version. These approaches work until they fail catastrophically - and they fail in ways that are difficult to recover from.

The core problem is that software development involves multiple overlapping concerns that are hard to manage without tooling: tracking what changed, who changed it, and why; supporting concurrent work by multiple developers on the same codebase; enabling recovery from mistakes without losing good work; and maintaining a history that can be audited and reasoned about. A version control system is the infrastructure that makes these concerns tractable.

Early centralized VCS tools like CVS (Concurrent Versions System, first released in 1990) and Subversion (SVN, released in 2000) made substantial progress. They introduced atomic commits, branch management, and meaningful history. But their centralized model imposed constraints that became increasingly painful as teams grew and internet connectivity became assumed: you needed network access and write permissions to the central server to commit anything, branching was expensive enough that developers avoided it, and the server was a single point of failure. When the Linux kernel's maintainers lost access to their VCS in 2005 due to a licensing dispute with BitKeeper, Linus Torvalds built a replacement in two weeks that addressed these constraints directly.

What Makes Git Distributed - and Why It Matters

Git's defining architectural property is that every clone of a repository is a complete, independent copy of the entire project history. Not a working copy that references a central server, but a full repository with every commit, every branch, and every version of every file ever tracked. This has practical consequences that go beyond the obvious benefit of offline access.

When you git clone a repository, Git copies every object in the origin's object store to your local .git directory. Operations that would require a network round-trip in a centralized system - viewing history, creating branches, diffing between versions, searching commit messages - happen entirely locally and are correspondingly fast. This also means that if the remote repository disappears, any clone can serve as a complete backup from which the project can be fully restored. The "remote" is not a privileged server; it is simply another repository that your team has agreed to treat as the canonical reference point.

The distributed model also changes the collaboration topology. Centralized systems assume a hub-and-spoke model: all developers commit to the same server. Git supports this topology - it is how GitHub-based workflows operate - but it also supports others: peer-to-peer sharing between developers, a maintainer-based model where changes flow through patches and pull requests, or multiple remotes representing different deployment environments. Git's fetch and push operations are symmetric: any two repositories can exchange objects and references. The workflow you impose on top of that capability is a social convention, not a technical constraint.

How Git Stores Data: Objects and the DAG

Understanding Git's internal data model is not academic pedantry - it is the mental model that makes every Git command interpretable rather than mysterious. Git stores all content in a simple but powerful structure: a content-addressable object store, where every object is identified by the SHA-1 hash of its content.

There are four object types. A blob stores the raw content of a file. A tree stores a directory listing - a collection of pointers to blobs (files) and other trees (subdirectories), along with names and permissions. A commit stores a pointer to a tree (the root of the project snapshot at that moment), pointers to parent commits, author and committer metadata, and the commit message. A tag stores a named pointer to another object, usually a commit. The entire history of a repository is a directed acyclic graph (DAG) of these objects. Branches and tags are simply named references - files in .git/refs/ containing the 40-character SHA-1 hash of the commit they point to.

# Inspect the raw object types Git stores
git cat-file -t HEAD           # prints "commit"
git cat-file -p HEAD           # prints the commit object contents
git cat-file -p HEAD^{tree}    # prints the root tree object
git cat-file -p HEAD:src/index.ts  # prints the blob (file content)

# See what's actually stored in .git/refs
cat .git/refs/heads/main       # prints the SHA-1 of the tip commit
cat .git/HEAD                  # prints "ref: refs/heads/main"

This model has two important implications. First, since objects are identified by content hash, the same file content stored at different paths or in different commits produces exactly one blob object - Git deduplicates automatically. Second, since a commit's hash is computed from its content including the parent hash, any modification to history (changing a commit message, altering file content, reordering commits) produces a new object with a different hash. You cannot silently tamper with history; any change produces a detectable divergence. This is why git rebase creates new commits rather than modifying existing ones, and why force-pushing rewritten history to a shared branch is disruptive - you are replacing objects that others may already have.

Getting Started: Essential Commands with Context

Most Git tutorials list commands alphabetically or in some notional "beginner to advanced" progression. A more useful framing is to organize commands by which area of Git's three-zone model they operate on: the working tree (your files on disk), the index (also called the staging area - what will go into the next commit), and the repository (the object store, the .git directory).

Every core Git command is an operation between these three zones, and knowing which zones a command reads from and writes to eliminates most Git confusion. git add moves content from the working tree to the index. git commit moves content from the index to the repository. git restore moves content from the repository or index back to the working tree. git reset moves the HEAD pointer and optionally synchronizes the index and working tree to match.

# === SETUP ===
git config --global user.name "Paul Serban"
git config --global user.email "paul@example.com"
git config --global init.defaultBranch main
git config --global core.editor "code --wait"   # VS Code as commit editor

# === INITIALIZE OR CLONE ===
git init                         # create a new repo in the current directory
git clone https://github.com/user/repo.git   # full clone with all history
git clone --depth 1 https://github.com/user/repo.git  # shallow clone, no history

# === INSPECT STATE ===
git status                       # what's in the working tree, index, HEAD
git log --oneline --graph --decorate --all   # visual commit graph
git diff                         # working tree vs index
git diff --cached                # index vs HEAD commit
git diff HEAD                    # working tree vs HEAD (all uncommitted changes)

# === STAGING AND COMMITTING ===
git add src/auth.ts              # stage a specific file
git add -p                       # interactive staging: pick hunks to stage
git commit -m "feat(auth): add JWT token validation"
git commit --amend --no-edit    # add staged changes to the previous commit (local only)

# === BRANCHING ===
git switch -c feature/rate-limiting    # create and switch (preferred over checkout -b)
git switch main                        # switch to an existing branch
git branch -d feature/rate-limiting    # delete a merged branch

# === REMOTE OPERATIONS ===
git remote add origin https://github.com/user/repo.git
git fetch origin                  # download objects, don't merge
git pull --rebase origin main     # fetch + rebase instead of merge
git push -u origin feature/rate-limiting   # push and set upstream tracking
git push --force-with-lease       # safe force push: fails if remote has new commits

A few of these deserve extra attention. git add -p (patch mode) is one of the most valuable and underused Git commands: it walks through your changes hunk by hunk, letting you stage exactly the changes you want in the next commit and leave the rest unstaged. This makes it possible to make several unrelated changes to a file and commit them as separate, logically coherent commits - essential for maintaining a useful history. git pull --rebase avoids the spurious merge commits that git pull (which merges by default) creates when your local and remote branches have both advanced. --force-with-lease checks that the remote has not received new commits since your last fetch before allowing the force push, preventing the common accident of overwriting a colleague's work.

Branching, Merging, and the Question of History Shape

Branching in Git is cheap in a way that branches in many other systems are not. Creating a branch takes microseconds and a few bytes of disk space - it writes a 41-byte reference file. This low cost means that branches can and should be used liberally: for every feature, every bug fix, every experiment. The question is not whether to branch but how to manage the resulting topology.

The choice between merging and rebasing is the central debate in Git workflow design, and it is a genuine trade-off rather than a matter of taste. Merging preserves the true topology of how work was developed: a merge commit has two parents, and git log --graph shows the actual branching and convergence of work over time. This fidelity is valuable when the history of concurrent development is itself meaningful information. Rebasing produces a linear history by replaying commits on top of the target branch as if they had been written there originally. This is easier to read with git log, makes git bisect more effective, and produces cleaner git blame output. The standard professional practice is to rebase feature branches onto the target branch before opening a pull request (keeping your branch current and history linear) but to merge (or squash merge) when integrating the PR (preserving a record of the integration event).

# Rebase workflow: bring a feature branch current before PR
git switch feature/rate-limiting
git fetch origin
git rebase origin/main           # replay feature commits on top of latest main

# If conflicts arise during rebase:
# 1. Resolve conflicts in the marked files
# 2. git add <resolved-files>
# 3. git rebase --continue
# Or abort entirely: git rebase --abort

# Interactive rebase: clean up local commits before pushing
git rebase -i HEAD~4             # reword, squash, or drop the last 4 commits

# After rebase, force push with safety check
git push --force-with-lease origin feature/rate-limiting

git bisect deserves a mention here because it is one of Git's most powerful debugging tools and one of the least used. When you know a bug exists in the current commit but not in some earlier commit, git bisect performs a binary search through the history to identify which commit introduced the regression. It requires only that you can write a test that passes on good commits and fails on bad ones, and Git handles the binary search bookkeeping. This works most effectively when commits are atomic - each commit represents one logical change and does not break the build - which is a strong argument for that practice independent of any aesthetic preference.

Common Pitfalls and How to Avoid Them

The mistakes that cause the most pain in professional Git usage are not syntax errors - those are caught immediately. They are conceptual mistakes that produce valid Git operations with unintended consequences, often not discovered until a colleague is affected.

Force-pushing to shared branches is the most damaging. When you rewrite history (via rebase or amend) and force-push to a branch others have checked out, their local branches now have a different history than the remote. The next pull produces a confusing divergence, and resolving it correctly requires everyone affected to know what happened. The rule is simple: never rewrite history on any branch that more than one person uses. On private feature branches, rewriting and force-pushing is fine (using --force-with-lease). On main, develop, or any shared integration branch, it is an incident.

Committing secrets and large binaries are two common mistakes with long-term consequences. A password, API key, or private certificate committed to a repository - even if deleted in a subsequent commit - remains in the history and is trivially recoverable. If the repository is public, the secret must be treated as compromised immediately. Tools like git-secrets or gitleaks can be installed as pre-commit hooks to catch these before they are committed. Large binary files committed directly to Git cause repository size to grow unboundedly, since Git stores every version of every file in the object store. Git LFS (Large File Storage) solves this by storing binary content on a separate server and replacing it in the repository with small pointer files - it should be configured before any large binaries are added.

Meaningless commit messages are a slower-acting problem. fix, WIP, update, asdfgh - these messages destroy the value of git log as a communication tool. The commit message is the place where you explain why a change was made, which is information that code alone cannot convey. Six months later, when a regression is traced to a commit, the message is what tells the next developer whether this was an intentional change, a known trade-off, or an accidental omission. This is worth a minute of effort per commit.

Best Practices for Professional Git Usage

These practices are drawn from how effective engineering teams operate at scale. They are principles to reason from, not rules to memorize.

Commit atomically. An atomic commit represents one logical change - the smallest unit that is coherent on its own and leaves the codebase in a working state. This makes git revert effective when you need to undo a specific change without affecting others, makes git bisect accurate, and makes code review focused. When you find yourself writing a commit message that includes "and" to describe two separate things, that is a signal that the commit should be split.

Adopt a branching strategy that matches your deployment model. Trunk-Based Development - where all developers integrate to main frequently using short-lived branches and feature flags - works best for teams that deploy continuously. Gitflow - with explicit develop, release, and hotfix branches - suits teams with scheduled release cycles. The worst outcome is having no explicit strategy: different developers operate on different implicit assumptions and the repository becomes inconsistent.

Use .gitignore as a first-class engineering artifact. Every repository should have a .gitignore that excludes build artifacts, dependency directories (node_modules, __pycache__, .venv), editor configuration files, environment files with secrets, and OS-generated files (.DS_Store, Thumbs.db). The gitignore.io service generates solid starting templates for most technology stacks. Review .gitignore changes in pull requests - an inadvertent exclusion of important files can silently break builds for other developers.

Configure Git globally for your environment once. The global Git configuration (~/.gitconfig) sets defaults that apply to all repositories on your machine. At minimum, configure your identity (name and email), your preferred editor, the default branch name for git init, and a useful set of aliases. Aliases reduce friction for commands you run dozens of times a day.

# ~/.gitconfig - useful global configuration
[user]
    name = Paul Serban
    email = paul@example.com

[init]
    defaultBranch = main

[core]
    editor = code --wait
    autocrlf = input        # normalize line endings on commit (important on Windows)

[pull]
    rebase = true           # use rebase instead of merge for git pull

[push]
    autoSetupRemote = true  # automatically set upstream on first push

[alias]
    st = status
    lg = log --oneline --graph --decorate --all
    co = switch
    undo = reset HEAD~1 --mixed   # undo last commit, keep changes staged
    aliases = config --get-regexp alias

Analogies and Mental Models

Two analogies consistently help developers build accurate mental models of Git.

The commit graph as a timeline of snapshots, not a sequence of diffs. Imagine Git as a photographer who takes a complete photograph of your project at each commit - not a list of what changed between photos, but a full image every time. Storage is efficient because unchanged content is deduplicated (same blob hash), but conceptually every commit is a complete state. This is why git checkout <hash> can instantly reconstruct any past version: Git is not replaying a sequence of diffs, it is simply reading the snapshot referenced by that commit's tree object.

Branches as sticky notes on the timeline. A branch is not a copy of the codebase. It is a sticky note that says "the tip of this line of work is here." When you create a branch, you place a new sticky note at the current commit. When you commit on that branch, the note moves forward to the new commit. Merging is the act of taking the work marked by one sticky note and incorporating it at the location of another. Deleting a branch removes the sticky note but does not remove the commits - they remain in the object store until garbage collection.

These two models together explain most of Git's behavior. Confusion typically arises when developers think of branches as copies (leading to surprise at how cheap they are) or of commits as diffs (leading to confusion about rebase, which makes more sense as "re-photograph the same changes from a new starting point").

Key Takeaways

Five things you can apply immediately to improve your Git practice:

Learn git add -p. Patch-mode staging transforms how you construct commits. Instead of committing everything you changed, you select exactly the changes that belong together. This produces a more useful history and forces you to think about what each commit should represent before writing the message.
Switch from git pull to git pull --rebase. Configure this globally with git config --global pull.rebase true. Rebase-pulls keep your local history linear and avoid the clutter of spurious merge commits from routine synchronization.
Install a pre-commit hook for secrets scanning. Use gitleaks or git-secrets as a pre-commit hook. Secret exposure in git history is a security incident; catching it before commit is trivial compared to the alternative.
Write one-line commit messages in the present tense, with a body when the why matters. feat(auth): add refresh token rotation tells the next reader what changed and where. A body paragraph explaining why the previous approach was insufficient adds context that no amount of code comments can provide.
Use git bisect the next time you have a regression. Mark the current commit as bad, mark a known-good commit, write a test that returns exit 0 for good and exit 1 for bad, and run git bisect run ./test.sh. Git will find the culprit commit in O(log n) steps.

80/20 Insight

If there is one thing that produces the majority of Git competence, it is this: understand that Git is a DAG of immutable content-addressed snapshots, and that branches, tags, and HEAD are just named pointers into that graph.

Everything else follows from this. Rebase becomes "create new snapshot objects that replay these changes from a different starting point." Merge becomes "create a new snapshot object with two parents." Reset becomes "move a pointer, and optionally synchronize the index and working tree to the object it now points to." Reflog becomes "the log of where HEAD has pointed, which lets you recover any state Git has ever computed even if you 'lost' it."

Most Git panic - "I lost my commits," "my branch is gone," "the rebase went wrong" - resolves quickly when you know that objects in the store are never deleted immediately. git reflog shows every place HEAD has pointed in the last 90 days. If you can see the commit hash, you can recover the content. This recovery ability is available precisely because Git is immutable snapshots, not mutable diffs.

Conclusion

Git has become ubiquitous not because it was marketed effectively or adopted by a dominant platform - though GitHub accelerated it - but because its design genuinely matches the structure of collaborative software development. The distributed model, the content-addressed object store, the cheap branches, the composable commands: these are engineering decisions that solve real problems.

The payoff from understanding Git beyond the command surface is substantial. Developers who understand the object model can recover from any mistake. Developers who understand branching strategies can design workflows that match their team's deployment model. Developers who write good commit messages create a repository that serves as a primary source of institutional knowledge - a record not just of what the code does now, but of why it became what it is.

Start with the mental models: the three zones, the commit graph, branches as pointers. Run git cat-file -p HEAD and look at what Git actually stores. Set up a .gitconfig that reflects how you want to work. Use git add -p the next time you have more than one logical change in your working tree. These small shifts compound into a substantially different relationship with the tool - one where Git is predictable rather than mysterious, and where the history it maintains becomes genuinely useful rather than an afterthought.

References

Chacon, S., & Straub, B. (2014). Pro Git (2nd ed.). Apress. Available free at https://git-scm.com/book
Git Documentation. git-config(1). https://git-scm.com/docs/git-config
Git Documentation. git-bisect(1). https://git-scm.com/docs/git-bisect
Git Documentation. gitglossary(7). https://git-scm.com/docs/gitglossary
Git LFS Documentation. https://git-lfs.com
Conventional Commits Specification v1.0.0. https://www.conventionalcommits.org/en/v1.0.0/
Trunk Based Development. https://trunkbaseddevelopment.com
Driessen, V. (2010). A successful Git branching model. https://nvie.com/posts/a-successful-git-branching-model/
Stack Overflow Developer Survey 2022. https://survey.stackoverflow.co/2022/#section-version-control-version-control-systems
gitleaks - secrets detection for Git. https://github.com/gitleaks/gitleaks
gitignore.io - generate useful .gitignore files. https://www.toptal.com/developers/gitignore