Repos & Version Control

Repositories: A Folder with a Time Machine

A repository (or "repo") is a folder of code files (a codebase) with one superpower: every single change ever made is recorded. Who changed it, when, and exactly what they changed. You can scroll back through the entire history and see the project at any point in time.

Think of it like Google Docs version history, but for an entire project with hundreds of files. Every save point is permanent. Nothing is ever truly lost.

---

Git: The Time Machine

The tool that powers this history is called Git. It's the industry standard, and virtually every software team on earth uses it.

The key concept in Git is the commit. A commit is a snapshot, a save point. Every time a developer finishes a meaningful change, they commit it with a short message explaining what they did:

"Add loading spinner to data table"
"Fix email template missing user name"
"Update analytics query to include Q4 data"

Each commit records exactly which lines changed in which files. You can always go back to any previous commit. It's like undo, but with infinite history and the ability to jump to any point, not just the last step.

---

Branches: Parallel Universes

Here's where it gets interesting. Git lets you create branches, which are parallel copies of the codebase where you can work on changes without affecting the original.

Imagine you're editing a Google Doc and you want to try rewriting the whole introduction. You wouldn't just start deleting paragraphs. You'd make a copy first, experiment on the copy, and if it turns out well, paste it back into the original. Branches are that concept, built into the tool.

Every repo has a main branch (often called main). That's the "real" version, the one that's live, deployed, running in production. When you want to add a feature or fix a bug, you:

1. Create a new branch off main (your parallel copy)
2. Make your changes on the branch
3. When you're done, merge the branch back into main

This way, the main branch is always stable. Experimental work happens in branches. If something goes wrong on a branch, you just delete it. Main is untouched.

---

Pull Requests: The Review Gate

A pull request (or "PR") is a formal way of saying: "I finished my work on this branch. Can someone review it before we merge it into main?"

It's called a "pull request" because you're requesting that the main branch pull in your changes. A PR shows:

• What files were changed and exactly how
• A description of why the changes were made
• Comments and feedback from reviewers

This is the quality gate. Before any code reaches the main branch, at least one other person looks at it. They might approve it, request changes, or ask questions. It's like having an editor review your writing before it's published.

In practice, a PR is a conversation. The developer explains their changes, reviewers ask questions, things get adjusted, and eventually everyone agrees it's ready. Then it merges.

---

CI/CD: The Robots That Test and Deploy

Here's where automation enters the picture. When you merge a pull request into the main branch, you don't manually copy files to a server. Instead, an automated pipeline takes over:

CI (Continuous Integration): the moment code is merged, automated tests run. Did the new code break anything? Do all the existing features still work? If a test fails, the team gets notified immediately.

CD (Continuous Deployment): if all tests pass, the code is automatically deployed to the live server. No human intervention. Push to main, tests pass, it's live.

This is the pipeline:

Developer merges PR into main
    → CI system detects the change
    → Runs automated tests
    → If tests pass: builds the app
    → Deploys to the hosting platform
    → The live service is updated

The entire flow, from merge to live, typically takes 2 to 5 minutes. No one manually uploads files. No one manually restarts servers. The robots handle it.

---

GitHub: Where Repos Live Online

Repos live on your computer while you're working, but they also need a home online where the whole team can access them. That's GitHub, a website that hosts Git repositories.

Think of GitHub as Google Drive for code. Your files live there, anyone with access can see them, and all the version history is preserved. But GitHub adds collaboration features on top:

• Pull requests happen on GitHub (the review and discussion)
• Issues track bugs and feature requests
• Actions run the CI/CD pipelines
• Access control determines who can see and edit what

Most software projects live in a GitHub repository. When someone says "check the repo," they mean go to the project's page on GitHub and look at the code, history, or open pull requests.

---

The Full Picture

Let's put it all together. Here's how software gets built, from idea to live product:

1. The codebase lives in a repo on GitHub
2. A developer creates a branch to work on a change
3. They make commits as they go, saving snapshots
4. When done, they open a pull request for review
5. After approval, the PR is merged into the main branch
6. CI/CD automatically tests and deploys the change
7. The live application is updated within minutes

This cycle repeats dozens of times a week across the team. It's the heartbeat of software development.

---

Further Reading