What the F**k is Git

Hey everyone!

Welcome to the first lesson! Okay so for the first one, I’m going to combine the two lessons in the “Git Basics” section of The Odin Project. The first one was more of the lesson on explaining what it is and why it’s important, while the second one was an assignment to apply what you learned as well as learn the common terminal Git commands.

First off, what the fuck is Git? Good question! It’s essentially a save button on steroids.

See, a normal save button on a text doc just overwrites the file. You only have the current version. If you wanted to see what you wrote two days ago, you’d have to have saved a separate copy, like My-Document-v2-FINAL-actually-final-v3.doc. It’s a mess.

Git is different. It keeps track of every single save (or “commit”) you make, across multiple files and folders. It’s a time machine for your entire project. This not only helps you track how much your project has grown, but it also lets you revert back to a past version if you break something.

Git is a type of “Version Control System,” or “VCS” for short. There have been a few iterations, but Git is the most popular. To understand why, you gotta know the three types.

1. Local VCS: This is the old-school way. It’s a database stored locally on your device. It basically just keeps a record of the changes (or “patch sets”) on your single computer. Want to collaborate? You can’t. Computer dies? You’re completely screwed.

2. Centralized VCS (CVCS): This was the next step. Instead of the database being on one computer, it’s stored on a central server. This is way better! It allows for multiple people to access the database and work on a project together. But it has one giant, glaring problem: if that central server goes down, the whole team is screwed. One single point of failure.

3. Distributed VCS (DVCS): This is the big one. This is Git. With a DVCS, there are redundancies. When you work on a project, you don’t just pull one file; you pull down a full copy of the entire project and its history. If the main server explodes, who cares? You can spin it right back up using any of the copies each developer has on their computer. It’s the best of both worlds.

Git’s “Special Sauce”

So what makes Git so special, besides being a DVCS? It’s the way it saves.

Instead of just remembering the differences between each version (like “you added this line”), Git just takes a giant “screenshot” (they call it a “snapshot”) of the current state of your entire project every time you commit.

And it’s smart. If you didn’t change a file, it doesn’t re-save a new copy; it just links to the old one. It’s super efficient, but it means every “save” is a complete picture of your project at that exact moment.

The “Three States” (The Actual Workflow)

Okay, this was the part that confused me at first, but it’s the whole workflow. Git has “Three States” for your files.

1. Modified: You changed a file. You typed some code, deleted a line, whatever. Git sees it’s different from the last snapshot, but you haven’t “saved” it in the Git way yet.

2. Staged: This is the weird, new step. Think of it like putting your files in a virtual “box” that you’re getting ready to mail. You use a command to selectively tell Git, “Okay, I want this file and this file to be in my next save.” You don’t have to add all your modified files, just the ones that are ready.

3. Committed: This is the actual “save” button. Git takes everything in your “staged” box, takes that snapshot, and saves it permanently to your local project history (which it calls your “Git directory”).

That’s the loop: You Modify files, you Stage the ones you want to save, and you Commit the staged files.

Wait… so what’s GitHub?

Last bit of theory, I promise. For the longest time, I thought “Git” and “GitHub” were the same thing. They are not.

• Git is the tool on your computer. It’s the version control software itself. It’s what does all the tracking, snapshotting, and history-keeping on your local machine.

• GitHub (or Bitbucket, or GitLab) is the website where you store your project. It’s a cloud-based platform that’s built to host Git repositories. It’s how you back your shit up, showcase it to employers, and (most importantly) collaborate with other developers.

The common workflow is: you work on your project on your own computer, using Git to commit your changes. Then, when you’re ready, you “push” those commits up to GitHub to save them remotely.

The Basic Commands (The “How-To”)

Okay, that’s the theory. The second part of the lesson was actually doing it. Here are the bare-bones commands I learned that make this all happen. The general syntax is program | action | destination.

• mkdir directory_name This just makes a new folder (a “directory”).

• cd directory_name This lets you “change directory” and move into the folder you just made.

• git clone [URL] This is how you copy an existing project (repository) from GitHub down to your computer.

• git status This is your new best friend. Seriously. Type this all the time. It tells you what’s going on: what files are modified, what files are staged, and what files Git isn’t tracking at all (anything in red).

• git add [file_name] This is how you stage a file. You’re putting that file into the “ready box” for the next commit.

• git commit -m “your message here” This is the “save” button. It takes the snapshot of all your staged files and saves it with a message describing what you did (the -m is for “message”).

• git push This is the command that sends all your saved “commits” from your local computer up to the repository on GitHub.

Okay, that’s it for the first couple of lessons. It was a ton of theory, but the main takeaway is that new workflow: Modify files, Add them to the staging area, and Commit them to your local history. Then Push to GitHub to back it all up.

Alright, now that we’re finally done with that. Lets move on to HTML. Also, if I missed anything or got anything wrong, feel free to leave a comment.