Git / version control
A system for tracking changes to files over time, enabling collaboration, history review, and the ability to restore prior versions. Git is the most widely used version control system.
Also known as: Git, version control, VCS, source control
Version control is a system for tracking changes to files over time. It records every change, who made it, when, and why, enabling collaboration, history review, and the ability to restore prior versions. Git is by far the most widely used version control system today, originally created by Linus Torvalds in 2005 to manage Linux kernel development.
Version control is essential infrastructure for software development and is increasingly used for content (writers, designers, documentation teams) as well.
What version control provides
- History. A complete record of every change to the project
- Collaboration. Multiple people can work on the same project without overwriting each other
- Branching. Parallel lines of development that can be merged later
- Recovery. The ability to restore previous versions or undo mistakes
- Attribution. Knowing who made each change and when
- Coordination. Mechanisms to review proposed changes before they merge
- Backup. Distributed copies of the entire history reduce single points of failure
How Git works
Git tracks changes through a series of commits, snapshots of the project at points in time. Each commit:
- Has a unique identifier (a SHA hash)
- References its parent commit(s)
- Includes the author’s name, timestamp, and a commit message
- Records the differences from the previous commit
A repository’s full history is a chain (or graph, with branches and merges) of these commits.
Common Git operations
| Command | Purpose |
|---|---|
git init | Create a new repository |
git clone <url> | Copy a remote repository locally |
git status | See what has changed |
git add <file> | Stage changes for the next commit |
git commit -m "message" | Save staged changes as a commit |
git push | Upload commits to a remote repository |
git pull | Fetch and merge changes from remote |
git branch <name> | Create a new branch |
git checkout <branch> | Switch branches |
git merge <branch> | Combine another branch into the current one |
git log | View commit history |
git diff | See differences between versions |
Most operations can also be performed through Git GUI tools (Sourcetree, GitKraken, GitHub Desktop, Tower) or directly inside code editors (VS Code, JetBrains IDEs).
Branching and merging
A branch is a parallel line of development. The default branch is typically called main (formerly master).
A common workflow:
- Create a branch for a new feature:
git checkout -b feature/contact-form - Make changes and commit them
- Push the branch to a remote
- Open a pull request (or merge request) for review
- Other team members review the changes
- Once approved, merge the branch into
main - Delete the merged branch
This pattern lets multiple people work on different features simultaneously without disrupting each other.
Git hosting platforms
Repositories are typically stored on hosted platforms that add collaboration features:
| Platform | Notable features |
|---|---|
| GitHub | Largest platform; pull requests, Issues, Actions for CI/CD, Pages hosting |
| GitLab | Self-hostable; integrated CI/CD, Issues, Wiki |
| Bitbucket | Atlassian platform; integrates with Jira |
| Codeberg | Free, open-source, community-supported |
| Gitea / Forgejo | Self-hosted lightweight alternatives |
| SourceHut | Email-driven workflows; minimalist |
| Cloudflare | Recently announced repository hosting |
GitHub dominates open-source and most commercial development; the others serve specific niches or self-hosted needs.
Distributed version control
Git is distributed: every clone of a repository contains the full history. This differs from earlier centralized systems (Subversion, CVS) where the history lived only on a central server.
Distributed advantages:
- Work offline; commit changes without network access
- Faster operations (most actions are local)
- Resilient to server outages
- Multiple remotes possible (push to backup repositories, fork projects)
Git for non-developers
Increasingly, non-developers use Git for:
- Writers. Tracking edits to manuscripts, drafts, or documentation
- Designers. Versioning design files (especially with Figma’s Git-aware features or specialized design version control)
- Researchers. Maintaining datasets and analysis scripts
- Lawyers. Tracking contract revisions
- Content teams. Managing website content stored in Markdown
Tools like GitHub Desktop, Tower, and editor integrations make basic Git operations accessible without command-line knowledge.
Git for website content
For static / code-based sites, Git is the primary content workflow:
- Markdown content lives in a Git repository
- Edits are committed and pushed
- A hosting platform (Cloudflare Pages, Netlify, Vercel) detects the push and rebuilds
- The new version goes live within seconds to minutes
This approach offers:
- Audit trail for every content change
- Preview deployments for proposed changes (each branch gets its own URL)
- Easy rollback if a change breaks something
- Multiple contributors without conflicting edits
- Backup through distributed copies
Beyond Git: other version control systems
| System | Status |
|---|---|
| Mercurial | Distributed VCS similar to Git; smaller user base |
| Subversion (SVN) | Centralized; still used in some legacy environments |
| Perforce | Centralized; popular in game development for binary asset handling |
| Plastic SCM | Owned by Unity; targets game development |
| Pijul | Patch-based; experimental |
| Sapling | Meta’s source control system |
Git is dominant for general-purpose software development; other systems serve specific niches.
Common misconceptions
- “Git is just for programmers.” Git is useful for any work involving text files where history matters.
- “Git and GitHub are the same.” Git is the underlying technology; GitHub is one of many hosting platforms that use Git.
- “You need to know Git from the command line.” Many users work effectively through GUIs and editor integrations.
- “Version control is overkill for small projects.” The overhead is minimal; the safety benefits apply at any scale.