I still remember the first time someone told me to "just push it to Git." I nodded like I understood. I did not understand. I went home and stared at my terminal for twenty minutes wondering if I'd broken my laptop.
Nobody ever sits beginners down and explains this stuff properly. It's always thrown at you in half-sentences, mixed with jargon, assuming you already know what a "repo" is. So let's fix that. No fluff, no pretending you already know things, and definitely no pretending this is more complicated than it is.
Here's the one sentence that will save you a lot of confusion: Git saves your work. GitHub shares your work. That's the entire relationship. Everything else is just details on top of that.
Why This Even Exists
Picture this. You're cooking dinner, and you decide to try adding chili flakes to your grandmother's pasta sauce recipe. If it goes badly, you want to go back to the original recipe without having to remember it from memory. If it goes well, you want to keep both versions somewhere safe, maybe even show your sister so she can try it too.
That's exactly the problem Git and GitHub solve, except with code instead of pasta sauce.
Git is the notebook where you jot down every version of the recipe as you go. GitHub is the family group chat where you share your notebook so everyone else can see it, copy it, or suggest you use less chili next time.
Setting Up Git (You Only Do This Once)
First, install Git from git-scm.com. Once it's installed, open your terminal and check it worked:
git --versionIf a version number shows up, you're set. Now tell Git your name and email, so every change you make gets labeled with who did it.
git config --global user.name "Your Name"
git config --global user.email "[email protected]"Think of this like writing your name inside the front cover of a school notebook. You do it once, and it sticks around forever.
Starting a Project
Go into your project folder and tell Git to start paying attention to it.
cd my-project
git initThis is basically Git walking into the room, looking around, and saying "alright, I'll keep an eye on everything from here." Nothing is being saved yet. It's just watching.
Saving Your Work: Add and Commit
This part trips up almost everyone at first, mainly because it happens in two steps instead of one.
Step one, staging:
git add sauce.pyThis is you picking up the file and putting it on the counter, saying "this one's ready to go into the notebook." You haven't written it down yet. You've just decided it's worth saving.
Step two, committing:
git commit -m "Added chili flakes to the sauce"This is the actual entry in the notebook. A little note describing what changed, plus a permanent snapshot of your file at that exact moment.
If you skip staging and go straight for commit, Git will just stare at you blankly, because it doesn't know what you want saved yet. Staging first, committing second. Always in that order.
Making a GitHub Account and Repository
Go to github.com and sign up, it's free. Click the green "New repository" button, give your project a name, and leave it empty for now. Don't add a README or anything yet.
This is you building an empty shelf in the cloud where your notebook will eventually live.
Connecting Your Project to GitHub
GitHub will show you a link right after you create the repository. Use it like this:
git remote add origin https://github.com/yourname/my-project.gitAll this does is tell Git, "when I say send this somewhere, send it here." Nothing gets uploaded yet, this is just setting the address.
Uploading Your Work
Now for the actual upload.
git push -u origin mainBreak that sentence apart and it stops being scary:
- push means send it up
- origin is the nickname for your GitHub address
- main is the name of your main branch, the "official" version of your project
Refresh your GitHub page and there it is. Your notebook is now sitting on the shelf for anyone with the link to see.
Branches, or How to Experiment Without Ruining Dinner
Here's where the pasta sauce analogy really pays off.
Say you want to try adding chili flakes, but you're not sure your family will forgive you if it's terrible. So instead of touching the actual recipe, you photocopy it, scribble your chili flake idea on the copy, and taste-test that version separately. If it's good, you copy the change into the real recipe. If it's bad, you just throw the photocopy in the trash and nobody ever has to know you almost ruined Sunday dinner.
That photocopy is a branch.
git checkout -b spicy-experimentNow anything you do happens on this separate copy. Your main recipe, sitting safely on the main branch, is untouched.
git add .
git commit -m "Tried chili flakes, verdict pending"Merging: Making the Experiment Official
Let's say the chili flakes were a hit. Time to fold that change back into the real recipe.
git checkout main
git merge spicy-experimentTranslation: go back to the real notebook, then copy over everything good from the experiment. If Git can figure out how to combine the two without confusion, it just does it. If two people changed the exact same line differently, Git will ask you to pick a winner, which people call a merge conflict. It sounds dramatic but it's really just Git saying "you two need to agree on something before I proceed."
Pull Requests: The Part Git Doesn't Actually Know About
Here's something that surprises people. Git has no idea what a pull request is. None. Zero concept of it. Pull requests are entirely a GitHub invention, sitting on top of Git, not inside it.
A pull request is you pushing your branch to GitHub and then saying, out loud, to your team, "hey, before I mix this into the main recipe, can someone taste it first?"
On GitHub, this looks like:
git push -u origin spicy-experimentThen on the website, click "Compare and pull request," write a short note about what you changed, and submit it. Somebody reviews it, maybe leaves comments, maybe asks you to use fewer chili flakes, and once everyone's happy, they click merge.
This is the collaboration layer GitHub adds. Git handles the saving and history. GitHub handles the conversation around it.
Getting Everyone Else's Changes
If your sibling also added something to the recipe and pushed it to GitHub, you'll want that update on your own computer too.
git pull origin mainYou're just asking the shelf, "anything new since I last checked?" and it hands you whatever's changed.
Actually Putting Your Project Online
Once your code lives on GitHub, you can make it publicly visible as a real website using GitHub Pages, which is free and works well for simple sites.
Go to your repository, click Settings, then Pages, choose the main branch, and save. GitHub will hand you a link that looks like:
https://yourname.github.io/my-projectPush new changes to main, and the live site updates automatically. No servers to manage, no hosting bill, no drama.
The Mistakes Almost Everyone Makes
Assuming committing and pushing are the same thing is probably the most common one. Committing saves your work locally, on your machine only. Pushing sends it somewhere else. Plenty of people have lost work assuming it was "backed up" when really it was just sitting, uncommitted, on a laptop that later died.
Another one is force-pushing without understanding what it does. It rewrites history on GitHub, and if other people already pulled the old version, you've just handed them a confusing mess to untangle. Use it carefully, and mostly avoid it until you know exactly why you need it.
And the classic one, treating "Git" and "GitHub" as interchangeable words. It causes people to look for features in the wrong place, like searching for a "revert" button on GitHub's website when it's actually a Git command you run locally.
Putting It All Together
The entire journey looks like this, start to finish:
Write your code, stage it, commit it, push it to GitHub, maybe branch off to try something risky, open a pull request to get it reviewed, merge it back into main, and deploy it so the world can see it.
None of these steps are complicated on their own. The confusion usually comes from nobody explaining which tool is responsible for which part. Once that separation is clear in your head, the commands stop feeling like magic spells and start feeling like exactly what they are, just labeled instructions for things you already understand.
One Last Thing
You genuinely don't need to memorize every Git command that exists. Five will get you through almost everything as a beginner: init, add, commit, push, and pull. Branching and pull requests come naturally once those five feel automatic.
Commit early, commit often, and don't be afraid to make a branch just to try something dumb. Worst case, you throw it away. Best case, your chili flakes turn out to be exactly what the recipe needed.