Git Explained for Beginners (Without the Confusing Parts)

You've heard everyone say "just push it to GitHub." You nodded. You have no idea what that means.

Or maybe you've memorized git add ., git commit -m "stuff", git push like a magic spell, and the day something goes wrong you have no clue what to do. Delete the folder and clone again? Yeah, I've seen that. I've done that.

Git isn't hard because the commands are hard. It's hard because nobody explains what's happening underneath. Once you have the right picture in your head, the commands stop being spells and start making sense. Let me give you that picture.

1. Git Is a Save System for Your Code

Think about a video game with save points.

Before a boss fight, you save. If you die, you reload and try again. You don't lose the whole game, just the last few minutes. Some games even let you keep multiple save slots so you can try a risky path without wrecking your main run.

Git does exactly that for your project:

• A commit is a save point, with a note attached saying what changed
• Your history is the list of all your save points, so you can go back to any of them
• A branch is a separate save slot where you can try something risky
• Merging is bringing the results of one slot back into your main game

That's the whole idea. Everything else is details.

2. Git vs GitHub (They're Not the Same Thing)

This trips up almost everyone at the start.

Git is the tool that lives on your computer and tracks your changes. It works completely offline.

GitHub is a website that stores copies of your Git projects online, so you can back them up, share them, and work with other people. GitLab and Bitbucket do the same job.

If Git is the game, GitHub is the cloud save. You can play without the cloud, but the cloud is how you keep your progress safe and let friends join in.

3. The Three Places Your Code Lives

This is the part tutorials skip, and it's the reason git add confuses people.

Your code moves through three areas:

1. Working folder. The files you're actually editing right now.
2. Staging area. A waiting room where you choose which changes go into the next save.
3. Repository. The saved history, where your commits live.

Picture packing a bag before a trip. Your working folder is your whole room. Staging is the bag on the bed, where you place only what you're taking. The commit is zipping the bag shut and putting a label on it.

Why bother with staging? Because sometimes you've changed five files but only two belong to the same idea. Staging lets you save those two together with a clear note, and leave the rest for another commit. That's what keeps a history readable.

4. Your First Five Minutes with Git

First, tell Git who you are, once per computer:

git config --global user.name "Your Name"
git config --global user.email "[e-mail]"

Now make a project and start tracking it:

mkdir my-project
cd my-project
git init

git init turns the folder into a repository. Create a file, then check what Git sees:

echo "Hello Git" > notes.txt
git status

git status is your best friend. It tells you what changed, what's staged, and what Git isn't tracking yet. Whenever you feel lost, run it.

Stage the file, then save:

git add notes.txt
git commit -m "Add first notes file"

Now look at your history:

git log --oneline

You just made your first save point. That's the loop you'll repeat thousands of times: change files, git add, git commit.

5. Write Commit Messages Future You Will Thank You For

A commit message is the note attached to a save point. Compare these:

Bad	Better
update	Fix login button not responding on mobile
stuff	Add validation to signup form
final final v2	Refactor navbar into a reusable component

A good rule: your message should complete the sentence "This commit will..." in a way that makes sense. Keep the first line short and specific. When you're hunting for the moment a bug appeared three weeks from now, you'll be very glad you wrote real messages.

6. Branches: Try Things Without Fear

Here's where Git gets genuinely powerful.

The main line of your project is usually called main. A branch is a copy of your work where you can experiment. If it goes well, you bring it back. If it goes badly, you throw the branch away and main is untouched.

git switch -c add-dark-mode

That creates a new branch called add-dark-mode and moves you onto it. Make your changes, add, and commit as usual. When you're happy:

git switch main
git merge add-dark-mode

Now main includes your dark mode work. Small habit that will save you a lot of pain: one branch per feature or fix. Keep them small and short-lived.

7. Connecting to GitHub: Push, Pull, Clone

So far everything lives on your laptop. Time to sync with GitHub.

• git clone <url> copies an existing GitHub project to your machine
• git push sends your new commits up to GitHub
• git pull brings down commits that someone else (or another computer of yours) added

To connect a project you started locally, create an empty repository on GitHub, then link it:

git remote add origin https://github.com/your-username/my-project.git
git push -u origin main

After that first time, git push and git pull are all you need. A good habit: pull before you start working, so you begin from the latest version.

8. The Merge Conflict (It Looks Scary. It Isn't.)

Every beginner panics the first time they see this. Let me defuse it.

A conflict happens when two changes touch the same lines of the same file and Git can't decide which one wins. Instead of guessing, it stops and asks you. Open the file and you'll see something like this:

<<<<<<< HEAD
<h1>Welcome to my site</h1>
=======
<h1>Welcome to my portfolio</h1>
>>>>>>> add-new-heading

The top part is your current version. The bottom is the incoming one. Your job is simple: decide what the final text should be, delete the marker lines, and save. Then:

git add index.html
git commit

Done. Git just needed a human to pick a winner. Conflicts get easier the more often you commit small and pull often.

9. Undoing Mistakes (Without Panic)

Everyone makes mistakes. Here's a safe toolkit. First, run git status. It usually tells you the exact command you need.

• Throw away edits to a file you haven't committed:

  git restore notes.txt

Careful: this really discards those changes.

• Unstage a file you added by accident:

  git restore --staged notes.txt

• Undo a commit you've already shared, safely:

  git revert <commit-id>

This adds a new commit that cancels the old one, so nobody's history gets rewritten.

Two commands to treat with respect: git reset --hard and git push --force. Both can destroy work, and force-pushing can wipe out teammates' commits. If you're not completely sure what they'll do, don't run them yet.

10. Don't Commit Your Secrets

This one can genuinely hurt you, so read it twice.

Never commit passwords, API keys, or .env files. Once something is pushed to a public repo, assume the whole internet has seen it, even if you delete it a minute later. Bots scan GitHub for exposed keys constantly.

Use a .gitignore file to tell Git which files to skip:

.env
node_modules/
*.log

If you do accidentally push a key, don't just delete the file. Revoke and replace the key immediately, then clean up. Deleting the commit isn't enough.

11. The Cheat Sheet

What you want	Command
Start tracking a folder	git init
See what's going on	git status
Stage a file	git add <file>
Save a snapshot	git commit -m "message"
See history	git log --oneline
Make and switch to a branch	git switch -c <name>
Switch branches	git switch <name>
Merge a branch into the current one	git merge <name>
Download a project	git clone <url>
Send commits to GitHub	git push
Get latest changes	git pull

You don't need to memorize all of these today. Print them, tape them next to your screen, and they'll stick on their own.

12. Habits That Make Git Painless

• Commit small and often. Many small commits beat one giant one.
• Write real messages. Future you is a stranger who needs context.
• Pull before you start. Begin from the freshest code.
• Branch for every feature. Keep main clean and working.
• Run git status constantly. It costs nothing and prevents most surprises.

Now Go Break Something Safely

Make a throwaway folder, run git init, and go wild. Create a branch, mess up a file on purpose, create a conflict, and fix it. There's no better way to lose your fear of Git than breaking it in a place where nothing matters.

Ten minutes of that will teach you more than an hour of reading.

---

Let's Connect

I'm Prayush Adhikari, currently grinding through computer engineering, leading an IT club, and building my own company on the side. I write about Linux, productivity, and the honest side of being a developer.

Tell me in the comments what part of Git confuses you the most. I'll cover it in a follow-up.

• LinkedIn: linkedin.com/in/adhikareeprayush
• GitHub: github.com/adhikareeprayush
• Portfolio: prayushadhikari.com.np

What should I write next: how to read and understand error messages, or how to build your first portfolio website from scratch?