IT Literacy for Non-Developers #5: Git and Version Control — How Many People Edit One Codebase

IT Knowledge
5 min read

In the last post, we talked about the rollback that reverts to the previous healthy version when a new deployment causes a problem. Along the way, I left one question hanging. Where exactly is that earlier version stored, the one you roll back to? And when many developers edit the same code at the same time, how do they avoid overwriting one another’s work?

The answer to both questions is Git and version control. This is what developers are talking about when, dozens of times a day, they say “I committed it,” “I pushed it,” “we got a merge conflict,” or “please review my PR.” In this final post of the series, we’ll look at what Git is and why every development team uses it.

This series, IT Literacy for Non-Developers, consists of five parts.

  • #1 What Is a Website Made Of? — Frontend, Backend, and Database
  • #2 What Is an API? — The Promise That Lets Services Talk to Each Other
  • #3 Servers, the Cloud, and Deployment
  • #4 Bugs, Hotfixes, and Rollbacks — How Developers Respond to Incidents
  • #5 Git and Version Control — How Many People Edit One Codebase ← this post

Version Control Means Keeping a Systematic Record of Changes #

You’ve probably worked on a document and ended up with files like “proposal_final.docx,” “proposal_final_really_final.docx,” and “proposal_final_v3.docx.” You can’t tell which one is truly the latest, and even if you want to bring back a sentence you deleted yesterday, there’s no good way to do it.

Code is far more complicated than this. There can be hundreds of files, and many people edit them at the same time. So you need a way to automatically record who changed what, when, and why, and to let you roll back to any point you want at any time. This is version control.

Git Is a Tool for Managing a Codebase’s Change History #

Git is the most widely used version control tool today. Every time the code changes, it records that change, and it tracks who edited which part and how. And when you need to, it lets you roll back to any point in the past.

This is exactly why the rollback we saw in the last post is possible. Because Git stacks up the change history one entry at a time, you can pull back a problematic new version and quickly return to the previous healthy one. If the versions aren’t recorded, there’s nowhere to roll back to.

A Commit Is the Unit That Saves a Set of Changes Together #

In Git, the basic unit for saving a change is called a commit. You bundle one meaningful change together and save it with a short description, like “fix login bug.” Just as taking a photo captures a moment, a commit records a specific moment of the code.

These commits stacked in chronological order are the change history itself. “I pushed it” means you uploaded all the commits you built up on your own computer to a place everyone shares. A rollback is the act of returning to one of these stacked commits, to a point before the problem appeared.

Branches and Merges Let Many People Work at Once #

When many people edit the same code at the same time, their work can collide. Git solves this problem with something called a branch.

A branch is a working offshoot that splits off from the main branch. Each developer works freely on their own branch without worrying about anyone else. When the work is done, they combine that change back into the main branch - this is called a merge. “We got a merge conflict” means two people edited the same part in different ways, and someone has to step in and decide which of the two to keep.

GitHub Is an Online Space for Working Together #

Here it helps to distinguish between Git and GitHub. Git is the tool that manages changes, and GitHub is a service that hosts that Git repository online and helps many people work on it together. Think of it as the relationship between a tool and the space where you use that tool.

A phrase that comes up often on GitHub is PR, short for pull request. It’s a request you submit that says, “please merge the change I made into the main branch.” Your colleagues look over the change in that request and leave their comments, and this process is called a code review. Only once it passes review does the change get merged. This extra check, instead of combining immediately, greatly reduces mistakes.

Why Knowing This Makes a Non-Developer’s Job Easier #

Once you understand the big picture of Git, you can see how a development team works.

  • You can follow development conversations. Phrases like “I committed it,” “I opened a PR,” and “I’ll merge and deploy” start to sound like signals that tell you how far the work has come.
  • You can understand “it’s not in production yet.” When someone says “that feature is being worked on in another branch, so it hasn’t been merged yet,” it means they’re building it, but it hasn’t been merged into the main branch or deployed.
  • Version control isn’t just for development. The idea of recording who changed what, when, and being able to roll it back, is just as useful for design files or document work.

Wrapping Up the Series #

Across five posts, we’ve looked at the IT literacy that’s good for non-developers to know.

  • In #1, we saw that a website is made of a frontend, a backend, and a database.
  • In #2, we saw that those layers talk to one another through a promise called the API.
  • In #3, we saw that the backend runs on servers and the cloud, and is made public to users through deployment.
  • In #4, we saw that when problems arise, teams respond with hotfixes and rollbacks.
  • In #5, we saw that all of those changes are recorded and managed with Git.

Even if you never handle these words yourself, simply knowing what they mean makes your conversations with developers far clearer. You can follow what’s said in meetings, you can see why schedules are set the way they are, and when an incident hits, you can read the situation calmly. I hope this series serves as a small map for everyone who works alongside developers.

X