Originally published on CodingCush.
A Git commands cheat sheet is a short list of the commands you use again and again to save versions of your code, see what changed, work on branches and share your work online. You do not need to memorise hundreds of options. Twenty core commands cover almost all daily work: setting up, staging, committing, checking history, branching, merging, syncing with a remote and safely undoing small mistakes. Learn these well, in the order of a normal working day, and Git stops feeling scary and starts feeling like a reliable undo button for your whole project.
First, What Git Is Doing in Simple Words
Git tracks changes in a folder, called a repository. You tell Git which changes to save, Git stores a snapshot called a commit, and each commit remembers the one before it. That chain of snapshots is your project's history. You can return to any earlier snapshot, compare two of them, or let several people build separate lines of history and join them later.
The official site at git-scm.com describes Git as a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Distributed means every developer holds a full copy of the history, so most work happens offline, on your own machine, at full speed.
Set Up Once: config and init or clone
git config --global user.name "Your Name"
git config --global user.email "you@example.com"
git init
git clone https://github.com/user/project.git
git config stamps your name and email on your commits; do it once on each new computer. git init turns the current folder into a new repository. git clone downloads an existing project, including its full history, from a site like GitHub. Starting a project yourself means init; joining an existing one means clone. If Git is not installed yet, follow our guide to installing Git on Windows, Mac and Linux first, then come back to this sheet.
The Daily Loop: status, add, commit, diff
git status
git add index.html
git add .
git commit -m "Add contact form"
git diff
git diff --staged
git status is the command you will type most. It tells you which files changed, which are staged and which branch you are on. Run it whenever you feel lost; it is Git's friendly dashboard. git add moves changes into the staging area, the waiting room for your next commit. Adding one file is precise; git add . stages everything, which is handy but deserves a quick status check first, so a stray file does not hitchhike into history.
git commit -m saves the staged snapshot with a short message. Write messages in plain words about why or what, like "Fix login button on mobile", not "stuff" or "final final v2". Future you, reading history at midnight, says thank you. git diff shows changes you have not staged yet, line by line, and git diff --staged shows exactly what is about to enter the next commit. Checking the diff before committing is the habit that prevents most embarrassing commits.
The official Git website, git-scm.com, describing Git as a free and open source distributed version control system for projects of every size.
See History: log and show
git log
git log --oneline
git show HEAD
git show a1b2c3d
git log lists commits newest first, with author, date and message. The --oneline form squeezes each commit to one short line, perfect for a quick overview. git show opens one commit and displays exactly what it changed; HEAD means the latest commit, or you can paste a commit's short code from the log. History is not decoration. It answers the two questions developers ask weekly: when did this change, and what exactly changed with it?
Branches: branch, switch, merge
git branch
git branch new-login-page
git switch new-login-page
git switch -c new-login-page
git merge new-login-page
A branch is a movable label pointing at a commit: a safe line of work where you can experiment without touching the main line. git branch lists branches, creating one does not move you onto it, and git switch moves you there. The -c form creates and switches in one step, which is why you will see it everywhere. When the work is ready, switch back to main and git merge to bring that branch's commits in. Our full guide to Git branches explained walks through creating, switching, merging and deleting branches with pictures in words, so read it after this sheet.
Share and Sync: remote, push, pull, fetch
git remote -v
git push origin main
git pull
git fetch
A remote is a named address for another copy of the repository, usually on GitHub, and origin is the standard name for your main one. git push uploads your commits; git pull downloads new commits and merges them into your current branch. git fetch is pull's cautious cousin: it downloads without merging, so you can inspect first and merge when ready. The official Git reference documentation explains every command and option, and it is the right place to check an option before trusting a random comment online.
| Job | Command | Remember it as |
|---|---|---|
| See what is happening | git status | The dashboard |
| Stage changes | git add . | Pack the box |
| Save a snapshot | git commit -m "message" | Seal and label the box |
| Upload work | git push | Send the boxes |
| Download and merge | git pull | Receive and unpack |
| Undo a file change | git restore file | Put it back |
Undo Safely: restore and the Gentle Fixes
git restore index.html
git restore --staged index.html
git commit --amend -m "Better message"
git restore throws away uncommitted changes in one file, so use it only when you are sure that work is unwanted; there is no dustbin to recover it from. With --staged it simply unstages a file while keeping your edits. git commit --amend rewrites your latest commit, handy for fixing a typo in its message or adding a forgotten file, but only before you push it. Shared history is a promise to your team; rewriting your own unpushed history is housekeeping.
A Normal Working Day, Using Only This Sheet
Watch how the twenty commands join into one calm routine. You start with git pull to collect your team's latest work, then git switch -c to open a branch for today's task. While building, you run git status and git diff like glancing in a mirror, git add the finished pieces, and git commit them in small, honest steps. A typo in the last message gets a quick --amend. Before lunch you peek at git log --oneline and feel oddly proud of the tidy story forming. At the end, you switch back to main, git merge your branch, and git push. Nothing heroic happened, and that is exactly the point: good Git work is boring, regular and safe, like saving a document every few minutes instead of once at midnight.
Frequently Asked Questions
What is the most used Git command?
For most developers it is git status, followed by add, commit, push and pull. Status is the safe first step whenever you return to a project or feel unsure what state your files are in.
What is the difference between git fetch and git pull?
Fetch downloads new commits but changes nothing in your working branch. Pull downloads and then merges them into your current branch straight away. Fetch first when you want to look before you leap.
How do I undo my last commit but keep the changes?
Use git reset --soft HEAD~1. Your commit disappears from history, but all its changes stay staged in your files, ready to commit again in a better shape.
Do I need GitHub to use Git?
No. Git works fully on your own computer with no account and no internet. GitHub is simply a popular place to store a remote copy and collaborate with other people.
Why does Git ask for a commit message every time?
Because history is only useful if humans can read it. A clear message turns your commit list into a story of the project, which helps teammates, reviewers and your future self.
Conclusion
Keep this sheet near your keyboard for two weeks and a pattern will form: status, add, commit, branch, push, pull. Those few commands, used calmly and often, are ninety percent of real Git work. Commit small, write honest messages, check your diff, and Git will quietly protect every project you build.
Top comments (0)