Version Control and Git Explained: Branching, Commits, and Workflows

96% of Developers Use Git — Understanding It Deeply Separates Good Engineers From Great Ones

Stack Overflow's 2023 Developer Survey found that 96.65% of professional developers use Git for version control. It has effectively become the universal standard for managing source code. Yet most developers use only a fraction of Git's capabilities — committing, pushing, pulling — without understanding the mental model that makes Git's more powerful features click. That understanding is what separates confident contributors from developers who panic when a merge conflict appears.

Why Version Control Exists

Before version control systems, code changes were managed through manual file backups, naming conventions (code_final_v3_REAL_final.zip), and email attachments. The problems: no audit trail of who changed what and why, impossible to collaborate without overwriting each other's work, and no way to recover from a bad change without the backup being current.

Version control systems solve all of this. Every change is tracked with the author, timestamp, and a message explaining why. Multiple people can work on the same codebase simultaneously. Any version can be restored. The entire history is transparent.

Git's Core Mental Model

Git is a distributed version control system — every developer has a complete copy of the repository's entire history locally. This contrasts with centralized VCS (like SVN) where only the server has the full history. Distributed architecture means:

Working offline is fully supported — commits, branches, and history access work without network
No single point of failure — any clone can restore a repository
Fast operations — most commands read from local data, not a network server

Git tracks a directed acyclic graph (DAG) of commits. Each commit stores a snapshot of all tracked files plus a pointer to its parent commit(s). This graph structure enables powerful branching and merging.

The Three States of Git Files

State	Location	Description
Working Directory	Your local file system	Files you're currently editing; changes not yet tracked by Git
Staging Area (Index)	Git's intermediate buffer	Files marked for inclusion in the next commit; allows selective committing
Repository	Git's database (.git directory)	Committed snapshots permanently recorded in history

The staging area is Git's most misunderstood feature. It allows developers to make multiple changes to files but commit only specific changes — creating clean, logical commits that reflect one intent rather than a mix of unrelated edits.

Branching: Working in Parallel

A branch in Git is simply a movable pointer to a commit. Creating a branch is instantaneous — Git creates a new pointer, not a copy of the codebase. This makes branching cheap and encourages it liberally.

Common branch usage patterns:

Feature branches: Create a branch per feature or task; develop independently; merge when complete
Bug fix branches: Create a branch from the release branch; fix the bug; merge into both release and main
Release branches: Stabilize a version without blocking main development
Hotfix branches: Emergency fixes to production; bypass normal development cycle

Merging vs. Rebasing

Operation	What It Does	History Result	When to Use
Merge (fast-forward)	Advances main branch pointer to the feature branch tip; no merge commit	Linear; looks as if changes were made on main all along	Feature branch ahead of main with no divergence
Merge (three-way)	Creates a merge commit with two parent pointers	Non-linear; preserves branch topology; clearly shows when merge occurred	Preserving complete history of feature development; open-source contributions
Rebase	Re-applies commits from one branch onto another; rewrites commit history	Linear; looks like feature was developed after main changes	Cleaning up local branches before merging; keeping feature branch up to date
Interactive Rebase	Allows editing, squashing, reordering commits before publishing	Rewritten as specified	Cleaning commit history before pull request review

The golden rule of rebasing: never rebase commits that have been pushed to shared branches. Rebasing rewrites commit hashes — changing history that others have already built upon causes severe conflicts.

Team Workflows

Git Flow

A structured workflow using specific branch names and roles. Main branches: main (production) and develop (integration). Supporting branches: feature/, release/, and hotfix/ branches with defined merge targets. Git Flow suits teams with scheduled release cycles and need for strict separation between development and production.

Trunk-Based Development

Developers commit directly to a shared main branch ("trunk") with very short-lived feature branches (often merged within a day). Requires robust CI/CD to catch problems fast. Eliminates long-lived branch divergence. Used by Google, Facebook, and most elite engineering organizations. Enables continuous delivery.

GitHub Flow

Simple workflow: create a branch from main; commit; open pull request; review; merge. One long-lived branch (main) always deployable. Suitable for continuous delivery teams without complex release scheduling needs.

Pull Requests: Code Review as a Gate

Pull requests (PRs, or merge requests in GitLab terminology) formalize the code review process. A developer opens a PR to propose merging a branch. Teammates review the diff, leave comments, and approve or request changes. PRs serve multiple purposes:

Quality control — catch bugs, design issues, and security problems before they reach production
Knowledge sharing — reviewers learn what was changed and why; authors learn from feedback
Documentation — PR descriptions and discussions create permanent context for why code is the way it is
Compliance — regulated industries require documented approval workflows for code changes