Git for Beginners: The Commands You'll Actually Use

Git has well over 100 commands, and its manual pages can feel like they were written for people who already know Git. The good news: most developers use a small set of commands every day and look up the rest when they need them.

This tutorial follows a normal workday. You will start a project, save your work, try something on a branch, merge it, share it and then fix the mistakes that trip up every beginner. Run the commands as you read and you will have the core of Git in under an hour.

If you are still fuzzy on how Git relates to the hosting site, read Git vs GitHub first. The short version: Git is the tool on your computer, GitHub is one place to store and share what it tracks.

The 3 places your files live

Git makes sense once you know that every change moves through 3 areas:

1. Working directory. The files you see and edit in your folder.
2. Staging area (the index). A holding area where you line up the exact changes you want in your next snapshot.
3. Repository. The permanent history of committed snapshots, stored in a hidden .git folder.

You edit in the working directory, choose changes with git add, then record them with git commit. Almost every command in this guide moves changes between those 3 areas or between your repo and a remote copy.

One-time setup

Install Git from git-scm.com (macOS often has it already; check with git --version). Then tell Git who you are, because every commit records an author:

git config --global user.name "Your Name" git config --global user.email "you@example.com"

Many hosts and teams now name the main branch main. Git’s own documentation says its built-in default is still master for now, with a change to main planned for Git 3.0, and you can set your own default:

git config --global init.defaultBranch main

Starting a project and saving your work

Start a new repo in an existing folder:

git init

Or copy an existing one from GitHub, GitLab or a company server:

git clone https://github.com/example/project.git

Check what changed. This is the command you will run most:

git status

It tells you which branch you are on, which files changed, and which changes are staged.

Stage and commit. Pick what goes into the snapshot, then save it with a message:

git add index.html git add . git commit -m "Add signup form to homepage"

git add . stages everything in the current folder. Staging file by file is slower but helps you make small, focused commits.

Look at history:

git log --oneline git diff

git log --oneline shows one line per commit. git diff shows unstaged changes line by line; add --staged to see what is about to be committed.

Good commit messages say what changed and why in a short present-tense line, such as “Fix tax rounding on checkout page.” Your future self will thank you.

Branching and merging

A branch is a separate line of work. You use one for every feature or fix so the main branch always works.

Create a branch and switch to it:

git switch -c fix-checkout-button

git switch arrived in Git 2.23 in 2019 as a clearer alternative to the older all-purpose git checkout. You will still see git checkout -b in older tutorials; it does the same job here.

See and move between branches:

git branch git switch main

Merge finished work into main. Switch to the branch you want to update, then merge the other branch into it:

git switch main git merge fix-checkout-button

Handle a merge conflict. If both branches changed the same lines, Git stops and marks the file with <<<<<<<, ======= and >>>>>>> sections. Open the file, keep the right version (or combine them), delete the markers, then:

git add checkout.js git commit

Conflicts are normal, not a sign you broke something. Small branches merged often produce fewer and smaller conflicts.

Delete a merged branch:

git branch -d fix-checkout-button

Syncing with a remote

A remote is a copy of the repo somewhere else, usually named origin. If you cloned the project, it is already set up.

git push -u origin fix-checkout-button git pull git fetch

• git push sends your commits to the remote. The -u flag remembers the link so later you can type just git push.
• git pull downloads new commits and merges them into your current branch.
• git fetch downloads new commits without merging, so you can look before you combine.

On most teams you push a branch and open a pull request for review instead of pushing straight to main. That review step is usually where automated tests run as part of a CI/CD pipeline.

Undoing mistakes without panic

This is where beginners lose the most time. Match your situation to the right command.

Situation	Command	What it does	Safe on shared branches?
Edited a file and want it back as it was	git restore file.txt	Discards uncommitted edits to that file	Yes, but the edits are gone
Staged a file by accident	git restore --staged file.txt	Unstages it; your edits stay	Yes
Typo in the last commit message, not pushed	git commit --amend	Replaces the last commit	No, only before pushing
Forgot a file in the last commit, not pushed	git add file.txt then git commit --amend --no-edit	Adds it to the last commit	No, only before pushing
A pushed commit broke something	git revert <commit>	Adds a new commit that undoes it	Yes, the preferred option
Want to undo local commits but keep the changes	git reset HEAD~1	Moves the branch back; changes stay in your files	No, only for unpushed work
Want to throw away local commits and changes	git reset --hard HEAD~1	Moves back and overwrites your files	No, and it destroys work
Need to switch tasks with unfinished edits	git stash then later git stash pop	Shelves changes and brings them back	Yes

The rule of thumb from Git’s own documentation: git revert records new commits that reverse earlier ones, so history stays intact for everyone. git reset rewrites where your branch points, and the manual warns not to do that to commits you have already shared. --hard can overwrite files, so pause before using it.

Key takeaway: If a commit is already pushed, use git revert. If it is only on your machine, git reset or git commit --amend is fine. When in doubt, run git status and make a backup branch with git branch backup before trying anything drastic.

One more lifesaver: git reflog lists where your branch has pointed recently, so you can often recover commits you thought a reset had deleted.

A daily workflow you can copy

Here is a routine that covers most real work:

1. git switch main and git pull to start with the latest code.
2. git switch -c short-descriptive-name for today’s task.
3. Edit, then git status and git diff to review.
4. git add the changes that belong together and git commit -m "Clear message".
5. Repeat steps 3 and 4 in small commits.
6. git push -u origin short-descriptive-name and open a pull request.
7. After it merges, git switch main, git pull and git branch -d short-descriptive-name.

Also add a .gitignore file early. It lists files Git should never track, such as dependency folders, build output and .env files holding passwords or API keys. Committing a secret, even once, leaves it in history.

Where to go from here

You now know the commands behind most daily Git work. To build the habit:

• Put every personal project under Git, even small scripts.
• Practice conflicts on purpose: make 2 branches that edit the same line and merge them.
• Read the free Pro Git book on git-scm.com when you want the deeper model.
• Add your repos to a public profile as part of a tech portfolio, and pair this with other free ways to learn to code.

Git is also a standard topic in junior developer interviews, so practicing it pays off if you are working toward becoming a software engineer. Keep our glossary handy for terms like HEAD, origin and rebase as you meet them.

Sources

• Pro Git book (git-scm.com) — the 3-area model, branching and remotes
• git-init documentation — default branch name and init.defaultBranch
• git-switch documentation — creating and switching branches with -c
• git-revert documentation — revert records new commits that undo earlier ones
• git-reset documentation — soft, mixed and hard modes and the warning about shared history
• GitHub Blog: Highlights from Git 2.23 — introduction of git switch and git restore