Version Control Basics: Git for Non-Developers
If you've ever asked a developer about Git and gotten a 20-minute explanation involving branches, rebasing, and merge conflicts, you're not alone. Git is one of those tools that developers assume everyone understands, but most explanations are way too technical.
This post is for project managers, designers, founders, and anyone else who works with developers but doesn't need to become one. Here's what Git actually does and why you should care.
What Git Actually Is
Imagine you're writing a document. You save it as "proposal.doc". Then you make changes and save it as "proposal_v2.doc". Then "proposal_final.doc". Then "proposal_final_FINAL.doc". We've all been there.
Git solves this problem for code. Instead of making copies, Git tracks every change you make and lets you go back to any previous version. It's like having unlimited undo, but organized.
The technical term is "version control." But really, it's just organized saving with a time machine.
Why Developers Use It
Code breaks. A lot. Sometimes you make a change that seems fine, and then three days later you realize it broke something else. With Git, you can see exactly what changed and when. You can undo specific changes without losing everything else.
It also lets multiple people work on the same project without overwriting each other's work. This is huge for teams. Without version control, coordinating code changes would be chaos.
Key Concepts (Without the Jargon)
Repository (Repo)
A repo is just a project folder that Git is tracking. When someone says "check the repo," they mean look at the project's code and history.
Commit
A commit is a save point. It's a snapshot of the project at a specific moment. Each commit has a message explaining what changed, like "Fixed login bug" or "Added user profile page."
When you hear developers talk about commits, they're talking about these save points.
Branch
Imagine you want to try something risky without messing up the working version. A branch is a copy of the project where you can experiment. If it works, you merge it back. If it doesn't, you throw it away.
The main branch (often called "main" or "master") is the official version. Other branches are works in progress.
Merge
When you're happy with changes on a branch, you merge them into the main branch. This combines the experimental work with the official version.
Pull Request (PR)
Before merging, developers usually create a pull request. This is a formal way of saying "I made these changes, can someone review them before we add them to the main project?"
If you ever need to review or approve something, it's probably through a pull request.
What You'll See in Practice
When working with a development team, you'll likely encounter these situations:
Checking Progress
You might get links to pull requests for review. Even if you don't understand the code, you can read the descriptions and comments. Good teams write clear PR descriptions explaining what changed and why.
Deployments
Many teams deploy automatically when code is merged to the main branch. You might hear "it'll be live after the PR merges" or "we deployed main to production."
Rollbacks
If something breaks after a deployment, developers can quickly revert to a previous version. This is one of Git's superpowers. Instead of frantically trying to fix forward, you can undo and buy time to figure out what went wrong.
GitHub, GitLab, and Bitbucket
Git is the tool. GitHub, GitLab, and Bitbucket are websites that host Git repositories and add extra features like issue tracking, code review, and project management.
Think of Git as the engine and GitHub as the car. You can use Git without GitHub, but most teams use one of these services because they make collaboration easier.
GitHub is the most popular for open source and startups. GitLab and Bitbucket are common in larger companies.
When Non-Developers Use Git
You might not need to use Git directly, but some situations where non-developers interact with it:
- Editing documentation - Many teams store docs in Git. You might edit Markdown files directly on GitHub.
- Reviewing changes - Approving pull requests, even if you're just checking that the description matches the requirements.
- Tracking issues - GitHub Issues is a common way to report bugs or request features.
- Checking status - Looking at the repo to see what's been shipped recently.
Common Questions
Can I accidentally delete everything?
It's very hard to permanently lose work with Git. Even if you delete files, they exist in the history. Even if someone force-pushes (a more aggressive operation), there are usually backups.
What's a merge conflict?
When two people change the same part of a file, Git doesn't know which version to keep. A developer has to manually decide. This sounds scary but is usually straightforward.
Why do developers care so much about commit messages?
Good commit messages make it easy to understand what happened months later. "Fixed bug" is useless. "Fixed login timeout when password contains special characters" is helpful. When something breaks, clear history makes debugging faster.
What You Don't Need to Learn
Unless you're becoming a developer, skip:
- Command line Git operations
- Rebasing and cherry-picking
- Git internals and how it stores data
- Complex branching strategies
These are developer concerns. Understanding the concepts above is enough to communicate effectively with your team.
The Bottom Line
Git is how developers track changes and collaborate without chaos. You don't need to use it directly, but understanding the basics helps you communicate with technical teams and follow project progress.
When someone mentions commits, branches, or pull requests, you now know what they're talking about. That's usually enough.