Git has more than a hundred commands and many of them have dozens of options. The good news is that you need only about fifteen to work comfortably every day. This guide to Git basics covers those commands, in the order you will need them, and explains what each one actually does so you are not just copying spells from the internet.
Git is useful even if you work alone. It gives you a complete history of your project, lets you try ideas on a separate branch without breaking working code, and makes it easy to back up your work to a hosting service. For front-end developers, Git basics are an everyday job skill, which is why it appears in our front-end developer roadmap. Designers who hand off to developers also benefit from understanding it.
Three ideas to understand first
- Repository (repo): a project folder that Git tracks. The history lives in a hidden
.gitfolder inside it. - Commit: a saved snapshot of your files with a message, an author and a date. Commits form the project’s history.
- Three areas: the working tree (your files as they are now), the staging area or index (changes you have chosen for the next commit) and the repository (committed history). Most commands move changes between these three areas.
Tip: The staging area confuses beginners, but it is useful. It lets you edit five files and commit only the two that belong together, with a clear message.
One-time setup
Install Git from git-scm.com (on macOS it may already be available, and on Linux use your package manager). Then tell Git who you are. This name and email are written into every commit you make.
git config --global user.name "Priya Raman"
git config --global user.email "[email protected]"
# Name new repositories' first branch "main"
git config --global init.defaultBranch main
# Check your settings
git config --listThe init.defaultBranch setting matters because, according to the official documentation, Git’s built-in default name for the first branch is still master until Git 3.0 changes it to main. Most hosting services and teams now use main, so setting it once avoids confusion.
Starting a repository
There are two ways to get a repository: create one in an existing folder, or copy (clone) one that already exists online.
# Turn the current folder into a repository
cd portfolio-site
git init
# Or copy an existing repository, with its full history
git clone https://example.com/team/shop-website.gitThe everyday loop: status, add, commit
Most of your Git time is spent in this loop. Edit files, check what changed, stage the changes you want, commit them with a message.
git status # what has changed?
git diff # show unstaged changes line by line
git add index.html # stage one file
git add css/ # stage a whole folder
git add . # stage everything in this folder and below
git diff --staged # review what will be committed
git commit -m "Add contact section to home page"Run git status often; it is free and it tells you exactly where you are, and usually which command to run next. Before every commit, run git diff --staged to make sure you are not committing a debug line or a password.
Writing good commit messages
| Weak message | Better message |
|---|---|
| update | Fix footer overlapping content on small screens |
| changes | Add email validation to booking form |
| final final 2 | Replace hero image with compressed WebP version |
A useful habit: write the message so it completes the sentence “If applied, this commit will…”. Keep the first line short (around 50 characters is a common convention) and make one commit per logical change.
Reading history: log and show
git log # full history, newest first
git log --oneline # one line per commit
git log --oneline --graph --all # with a drawing of branches
git show a1b2c3d # details and diff of one commit
git log -- css/style.css # history of one fileEach commit has an ID (a long hash). You can usually use just the first seven characters, as shown by git log --oneline. Press q to leave the log view.
Ignoring files with .gitignore
Some files should never be committed: dependencies you can reinstall, build output, editor settings, and especially secrets. List them in a file named .gitignore at the root of the repository.
# Dependencies and build output
node_modules/
dist/
__pycache__/
# Secrets and local settings
.env
config.local.php
# OS files
.DS_Store
Thumbs.dbWatch out: .gitignore only affects files Git is not already tracking. If you committed a secret by mistake, adding it to .gitignore does not remove it from history. Change the password or key immediately, then clean up.
Project generators usually create a sensible .gitignore for you. For example, a new React project made with Vite already ignores node_modules and the build folder, as you will see in Build a React Project with Vite. For a WordPress theme, track only your theme folder, not the whole WordPress install; see WordPress theme development basics.
Branches: try things safely
A branch is a separate line of work. You create one for a new feature, commit to it freely, and merge it back when it is ready. Your main branch stays working the whole time.
git branch # list branches (* marks the current one)
git switch -c dark-mode # create a branch and switch to it
# ...edit, add, commit as usual...
git switch main # go back to main
git merge dark-mode # bring the dark-mode commits into main
git branch -d dark-mode # delete the branch once merged
git switch - # jump back to the previous branchgit switch is the dedicated command for changing branches. Older tutorials use git checkout for this, which still works but does many unrelated jobs, so switch is clearer for beginners.
Merge conflicts
If both branches changed the same lines, Git cannot decide which version to keep and reports a conflict. Do not panic. Open the file and you will see markers like this:
<<<<<<< HEAD
--brand: #1d4ed8;
=======
--brand: #0f766e;
>>>>>>> dark-mode- Edit the file so it contains the version you want, and delete the three marker lines.
- Stage the fixed file with
git add style.css. - Run
git committo complete the merge. If you would rather stop,git merge --abortreturns to the state before the merge.
VS Code shows conflicts with buttons such as “Accept Current” and “Accept Incoming”, which makes this easier. See our VS Code setup guide.
Working with a remote
A remote is a copy of the repository on another computer, usually a hosting service. It is your backup and the place where a team shares work.
git remote add origin https://example.com/priya/portfolio-site.git
git remote -v # list remotes
git push -u origin main # first push; -u remembers the link
git push # later pushes
git pull # fetch and merge others' changes
git fetch # download changes without mergingA good team habit: git pull before you start work, commit in small steps, and push at least at the end of each day.
Undoing things safely
This is where beginners get scared, and where copying random commands causes real damage. Use the gentlest command that solves your problem.
| Situation | Command | Notes |
|---|---|---|
| I edited a file and want the last committed version back | git restore index.html | Your uncommitted edits to that file are lost |
| I staged a file by mistake | git restore --staged index.html | Unstages it; your edits stay in the file |
| My last commit message has a typo (not pushed yet) | git commit --amend -m "New message" | Replaces the last commit; avoid after pushing |
| A commit that is already pushed broke something | git revert a1b2c3d | Creates a new commit that undoes it; safe for shared branches |
| I want to put my unfinished work aside for a moment | git stash, later git stash pop | Handy before switching branches |
Watch out: Be careful with git reset --hard and git push --force. Both can throw away work permanently, yours or your team’s. Learn them later, and never run them because a forum answer said so without understanding what they do.
A simple branching habit for small projects
You do not need a complicated workflow when you work alone or in a small team. This one is enough for most portfolio sites, client websites and learning projects:
- Keep
mainworking at all times. Anything onmainshould be ready to show or deploy. - For each feature or fix, create a short-lived branch with a descriptive name, such as
contact-formorfix-mobile-menu. - Commit small steps on that branch. It is fine if some of these commits are not perfect.
- When the feature works, switch to
main, pull the latest changes, and merge the branch. - Push
mainand delete the feature branch.
Teams that use a hosting service usually replace step 4 with a pull request (some services call it a merge request): you push the branch, a teammate reviews the changes in the browser, and the merge happens there. The Git commands underneath are the same ones you have just learned.
Your Git basics cheat sheet
| Command | What it does |
|---|---|
git init | Start tracking the current folder |
git clone <url> | Copy a remote repository |
git status | Show what has changed and what is staged |
git add <path> | Stage changes |
git commit -m "…" | Save staged changes as a commit |
git diff / git diff --staged | Show unstaged / staged changes |
git log --oneline | Compact history |
git switch -c <name> | Create and switch to a branch |
git merge <name> | Merge a branch into the current one |
git push / git pull | Send / receive commits |
git restore | Discard or unstage changes to files |
git revert <commit> | Undo a commit with a new commit |
Practise Git basics on a real project
Reading about Git basics is not enough; your fingers need to learn it. Take something small, such as the page you build in HTML Editors and Your First Page or your first week of Python exercises, and put it under Git. Make a commit after each lesson. Create a branch to try a new colour scheme, merge it, then deliberately cause and fix a conflict. Ten minutes of this teaches more than an hour of reading.
Designers can benefit too: when a developer says “that change is on the feature/new-header branch”, you will know what it means and how to preview it. Our design handoff checklist covers more of the shared vocabulary between designers and developers.
Frequently asked questions
What is the difference between Git and GitHub?
Git is the version control tool that runs on your computer and stores the history of your project. GitHub is one of several hosting services where you can keep a remote copy of a Git repository and collaborate with others.
Should I use git checkout or git switch?
For changing branches, use git switch, and use git restore for discarding file changes. git checkout still works for both, but because it does many different jobs, the newer commands are clearer for beginners.
How do I undo my last commit?
If you have not pushed it, git commit –amend lets you change the last commit’s message or contents. If it is already pushed and others may have it, use git revert with the commit ID, which adds a new commit that undoes the change.
Why is my default branch called master instead of main?
Git’s built-in default is still master until Git 3.0. Run git config –global init.defaultBranch main once, and new repositories will start with a branch called main.
Do designers need to learn Git?
Not deeply, but knowing the basics helps designers who write HTML and CSS, review front-end work or contribute to a design system’s code. Understanding commits and branches also makes conversations with developers easier.
