Git for Beginners: The Only 8 Commands You Need to Start

Every developer job uses Git. Every team project runs on it. And nearly every beginner learns it the same painful way: memorizing commands they don't understand until the day something goes wrong and they delete a week of work trying to fix it.

Here's the truth that makes Git learnable: daily Git is about 8 commands, and they all make sense once you understand one mental model. This guide gives you the model, the commands, and, most importantly, how to get out of trouble.

What Git actually is (30 seconds)

Git is a save-point system for your code. Like save slots in a video game, each commit is a snapshot of your entire project at a moment in time. You can look at old snapshots, compare them, and return to any of them. Nothing committed is ever truly lost, which is why the single best habit in programming is: commit early, commit often.

GitHub, by the way, is not Git. Git is the tool on your computer; GitHub is a website that hosts copies of Git projects so you can back them up and collaborate. You can use Git alone without GitHub just fine.

The mental model: three places your code lives

Every Git confusion dissolves once you know these three zones:

1. Working directory: your actual files, as you're editing them right now.
2. Staging area: a "loading dock" where you gather the specific changes you want in your next snapshot.
3. Repository history: the permanent chain of commits (snapshots).

The daily flow is always the same: edit files → stage the changes → commit them. That's it. Everything else is variations.

The 8 commands

1. git init: start tracking a project

cd my-project
git init

Run once per project. Creates a hidden .git folder where all history lives. Delete that folder and the history is gone; the folder is the repository.

2. git status: where am I?

git status

Your most-used command. Shows which files are modified, which are staged, and often literally tells you what command to run next. When in doubt, run git status. Twenty times a day is normal.

3. git add: stage changes

git add app.js        # stage one file
git add .             # stage everything changed

Puts changes on the loading dock. Why the extra step? Because it lets you commit related changes together: fix a bug in three files, stage and commit those three, keep your unrelated experiment out of it.

4. git commit: take the snapshot

git commit -m "Fix login redirect after password reset"

Saves everything staged as a permanent snapshot with a message. Good messages say what changed and why. "Fix bug" helps nobody, including future-you, who is the main audience.

5. git log: see the history

git log --oneline

The list of all your save points, newest first. The --oneline flag keeps it readable.

6. git diff: what exactly did I change?

git diff

Shows line-by-line changes you haven't staged yet. Run it before every commit; it's the fastest code review you'll ever get, and it catches the debug line you forgot to delete.

7. git push / git pull: sync with GitHub

git push    # upload your commits
git pull    # download teammates' commits

Push sends your local commits to the hosted copy; pull brings down anything new. Solo developers mostly just push (it doubles as a backup).

8. git checkout -b: branches

git checkout -b new-feature

A branch is a parallel line of save points: a safe sandbox for trying something without touching your working version. If the experiment works, you merge it back; if not, you throw the branch away and your main code never knew. Teams run entirely on this pattern: every feature and fix happens on its own branch.

Getting out of trouble (the section you'll bookmark)

Git panic comes from not knowing the undo commands. Here they are:

"I edited a file and want to throw the changes away":

git restore app.js

Careful: uncommitted changes discarded this way are genuinely gone. This is the one dangerous command in this article.

"I staged something I didn't mean to":

git restore --staged app.js

Takes it off the loading dock. The edits themselves are untouched.

"My last commit message has a typo" / "I forgot a file":

git commit --amend

Redoes the most recent commit. (Only amend commits you haven't pushed yet.)

"I want to undo a whole commit":

git revert abc1234

Creates a new commit that reverses the old one. History stays intact; this is the safe undo, always appropriate even on shared code.

The golden rule of Git trouble: if something is committed, it is recoverable; even things that look destroyed can usually be found with git reflog. So when confused, the safest move is to commit what you have first, then untangle. Never copy your project folder to project-final-v2-REAL out of fear; that's the habit Git exists to replace.

A .gitignore in 60 seconds

Some files should never be committed: dependency folders (node_modules/), build output, and especially secrets (.env files with API keys). List them in a file called .gitignore at your project root:

node_modules/
dist/
.env

Do this at project start, not after you've accidentally committed 40,000 dependency files. And if a real secret ever does get committed and pushed, revoke and rotate the key; deleting the file in a new commit does not remove it from history.

How to actually learn this

Reading about Git teaches you nothing durable; like all tools, it becomes muscle memory through use:

1. Today: git init in whatever project you're learning with, even solo exercise code.
2. Every session: commit when anything works. Small commits, honest messages.
3. This week: make a free GitHub account and push. Your code is now backed up, and you've done the workflow every job uses.
4. When comfortable: do one experiment on a branch and merge it.

If you're still early in your coding journey, build this habit alongside the code itself: committing your exercise solutions from our JavaScript or Python course as you go is exactly the kind of practice that makes both skills stick. A public GitHub profile with months of steady commits is also, quietly, the beginning of the portfolio that gets you your first job.