DEV Community: Jeffrey Payne

What the F**k is Git

Jeffrey Payne — Fri, 24 Oct 2025 16:09:45 +0000

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.

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.
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.
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.

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.
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.
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.

Welcome to my Journey Everyone!!

Jeffrey Payne — Fri, 24 Oct 2025 16:02:12 +0000

Hey everyone!

My name is Jeffrey Payne, and I’ve wanted to be a software engineer ever since I was in elementary school. I took my first coding class at the Apple Store when they were participating in the “Hour of Code” movement by Code.org, and I took Computer Science classes all through middle and high school. I even went to college for Information Science and Arts at the University of Arizona and was part of the group that won first place in the app development category of our senior showcase.

While it sounds like I should know how to build an app from the ground up or create an API, I don’t.

My main goal in those classes was just to pass, to get a grade good enough that I wouldn’t fall behind or end up on academic probation, risking my financial aid. Because of this, I focused more on “keeping up” than on actually understanding what was being taught. Professor Google and Lecturer Stack Overflow were my crutches during my entire 4-year degree. I’m not going to lie: I have no clue how my group and I were able to start with nothing and end up in first place for our senior showcase.

Since graduating, I’ve been struggling through the post-grad life for the last few months. All of the jobs I’ve seen or applied for require a skill set that I feel like I just don’t have. I’d try opening up LeetCode, and all the information I supposedly learned about data structures and algorithms was just nonexistent.

If you want me to write a simple Python script to go through a dataset, build a password generator, or make a call from a simple API off the top of my head, I absolutely can. Anything more complicated than that? Call someone else.

Because of this huge gap in knowledge, I spent most of this last year in a depressive state. I kept wondering if I just wasted four years of my life trying to get this degree but not getting anything in return, knowledge-wise. Instead of going for the job or career that I wanted, I ended up working this miserable IT help desk job at one of our local hospitals during the day and just sulking at night.

The post-grad depression was real... until I realized that I was the reason it was real.

For whatever reason, I felt like my life was over when it’s just beginning. I’m in my 20s and have free will (not to mention the internet), so why not just teach myself these skills? That’s when I hopped on Google and did some research. And that’s when I found The Odin Project.

The Odin Project is a free and open-source curriculum designed not only to teach you full-stack web development but also how to learn.

Now, you might be asking, “Why The Odin Project and not something like Codecademy or FreeCodeCamp?” Well, first off, I discovered The Odin Project through FreeCodeCamp, but I was drawn to the fact that you have to do everything yourself. There’s no integrated IDE with all the required packages installed for you right out of the box. Instead, you have a lesson, questions you should answer to make sure you understand the topic, and homework (yes, homework).

I’m at the point in my life where I want to learn, but on my own time. I want to get my hands dirty to understand something that interests me and not have to worry about a GPA or a grade. Not to mention, the reviews for this course have been crazy good.

Now… why the blog?

Well, in order for me to make sure that I fully understand a topic, I need to be able to explain it to others. I don’t have anyone else going through this journey with me, so I decided that after each lesson, I’m going to teach the topics that I learned right here to YOU.

Not only will this help me solidify the topic in my mind, but maybe we can build a community? You know, ask questions, hype each other up, and PLEASE call me out if I misunderstood something. I would rather be corrected than move on when I don’t understand a crucial topic.

Right now, I’m going to be starting the first “official” lesson once I get past the introductory and prerequisite sections. Does that mean I’m skipping them? Absolutely not. Not only do they help you prepare for this curriculum, but they also have actual info that will help you along the way. Please, please, PLEASE, do not skip them if you’re also thinking about starting The Odin Project.

That being said, welcome to the journey! I don’t know where we’ll end up, but I’m glad you’re here!