Git Commands Cheat Sheet
Every Git command a tester or SDET uses day to day, on one page — from first setup to recovering from mistakes. The restore, reset, stash, merge and recovery commands were checked in a real repository. For explanations, start with The Complete Git Tutorial.
Setup & Configuration
git config --global user.name "Nav"
git config --global user.email "nav@example.com"
git config --global init.defaultBranch main
git config --list # check your settings
git init # new repository in this folder
git clone <repo-url> # copy a remote repository
git remote -v # show remotes
git remote add origin <repo-url> # connect a local repo to a remote
Daily Workflow ⭐
git status # what changed?
git diff # unstaged changes, line by line
git diff --staged # what will be committed
git add LoginTest.java # stage one file
git add . # stage everything in this folder
git commit -m "Add locked-out user login test"
git pull --rebase # get others' work, replay yours on top
git push # upload (first time: git push -u origin <branch>)
Before every push
git status → git add → git commit → git pull --rebase → run the tests → git push
Pulling before pushing avoids the "rejected — non-fast-forward" error, and running the suite after the pull catches conflicts between your change and someone else's.
Viewing History
git log --oneline # one line per commit
git log --oneline --graph --all # branches drawn as a graph
git log -p -- src/test/java/LoginTest.java # changes to one file
git show <commit> # one commit in full
git blame LoginPage.java # who last changed each line
git diff main..feature/login --stat # files that differ between branches
Branching & Merging
git branch # list local branches (-a for remote too)
git switch -c feature/login-tests # create and switch (older: git checkout -b)
git switch main # switch branch (older: git checkout main)
git merge feature/login-tests # merge into the current branch
git merge --no-ff feature/login-tests # always create a merge commit
git branch -d feature/login-tests # delete a merged branch (-D forces)
git push origin --delete feature/login-tests # delete the remote branch
Resolving a merge conflict
<<<<<<< HEAD
your version
=======
their version
>>>>>>> feature/login-tests
- Edit the file to the correct final content and delete the markers.
git add <file>, thengit commit(orgit rebase --continueduring a rebase).- Run the tests before pushing. To give up instead:
git merge --abort.
Fetch vs Pull ⭐
| Command | Does | Changes your files? |
|---|---|---|
git fetch |
Downloads new commits from the remote | No — inspect with git log main..origin/main |
git pull |
Fetch + merge into your branch | Yes |
git pull --rebase |
Fetch + replay your local commits on top | Yes — linear history |
Stash
git stash # shelve uncommitted changes
git stash -u # include untracked (new) files
git stash list # stash@{0}: WIP on main: …
git stash pop # re-apply the latest and remove it
git stash apply stash@{1} # re-apply a specific one, keep it
git stash drop stash@{0} # delete one
Use it when you must switch branches for urgent work without committing half-finished changes.
Undoing Changes ⭐
| Task | Modern command | Older equivalent |
|---|---|---|
| Unstage a file (keep the change) | git restore --staged <file> |
git reset <file> |
| Discard local changes to a file ⚠️ | git restore <file> |
git checkout -- <file> |
| Fix the last commit (message or missing file) | git commit --amend — before pushing |
git commit --amend — before pushing |
| Undo the last commit, keep changes staged | git reset --soft HEAD~1 |
git reset --soft HEAD~1 |
| Undo the last commit, keep changes unstaged | git reset HEAD~1 (mixed, the default) |
git reset HEAD~1 (mixed, the default) |
| Undo the last commit and its changes ⚠️ | git reset --hard HEAD~1 |
git reset --hard HEAD~1 |
| Undo a pushed commit safely | git revert <commit> — adds a new commit |
git revert <commit> — adds a new commit |
| Preview deleting untracked files | git clean -n (then -f to delete) ⚠️ |
git clean -n (then -f to delete) ⚠️ |
reset vs revert: reset rewrites history — fine for local commits. revert keeps history and adds an "undo" commit — the right choice for anything already pushed. ⚠️ marks commands that throw work away.
Rebase, Cherry-Pick & Advanced
git rebase main # replay your branch on the latest main
git rebase -i HEAD~3 # edit, reorder or squash the last 3 commits
git cherry-pick <commit> # copy one commit to the current branch
git bisect start / good / bad # binary-search for the commit that broke a test
git tag -a v1.0 -m "Release 1.0" # mark a release (push with git push --tags)
⚠️ Don't rebase branches other people are using — it rewrites commit IDs. More: Rebase, Cherry-Pick & Bisect. See also: Git Branching and Merging.
"Oh No" Recovery Guide ⭐
| Problem | Fix |
|---|---|
Committed to main instead of a feature branch (not pushed) |
git branch feature/x (keeps the commit), then git reset --hard HEAD~1 on main, then git switch feature/x |
| Deleted a branch | git reflog → find its last commit → git branch <name> <commit> |
Accidental reset --hard |
git reflog → git reset --hard HEAD@{1} |
| Push rejected (non-fast-forward) | git pull --rebase, fix any conflicts, run tests, push again |
| Detached HEAD with new commits | git switch -c rescue-branch before switching away |
| Bad merge already pushed | git revert -m 1 <merge-commit> |
| Committed a password or token | Remove it and rotate the credential — it's in the history |
Force push
git push --force-with-lease # refuses if someone else pushed in the meantime
Only on your own branch after rewriting it (amend, rebase) — never on main. Prefer --force-with-lease over plain --force.
.gitignore for a Test Automation Project
# Build output and reports
target/
test-output/
allure-results/
playwright-report/
test-results/
# Logs, screenshots, local files
*.log
screenshots/
.idea/
*.iml
.DS_Store
node_modules/
# Local configuration with credentials
config/local.properties
.env
Commit framework code, test data and pipeline files; keep generated output, IDE files and secrets out.
Pull Requests
| Platform | Name |
|---|---|
| GitHub, Bitbucket | Pull Request (PR) |
| GitLab | Merge Request (MR) |
Branch → commit → push → open PR/MR → automated tests run → review → merge (often "squash and merge" for a tidy history). More: GitHub & GitLab: Pull Requests & CI/CD.
Test yourself before an interview with the Git Interview Simulator.
From Real Projects
In my automation roles I maintained test scripts that several people reviewed and extended — POM classes, the business library and data files all changing at once. That's exactly the situation version control is built for: every change reviewed, traceable and easy to undo. On Canolog, the many forms and screens across sales, inventory, finance and service are where keeping page details in POM classes and reusable steps in a business library paid off. Run git status before and after every command until it becomes a habit.
📚 Official documentation: Git documentation
FAQs
What's the difference between git switch and git checkout?
git switch (branches) and git restore (files) split up the many jobs of git checkout into clearer commands. Both styles still work.
How do I undo my last commit?
Not pushed: git reset --soft HEAD~1 keeps the changes staged. Already pushed: git revert HEAD.
How do I discard all local changes?
git restore . for tracked files, and git clean -n then git clean -f for untracked files — both permanently discard work.
What should a test automation .gitignore include?
Build and report folders (target/, test-output/, Allure or Playwright results), logs, screenshots, IDE files and local config with credentials.
fetch or pull?
fetch to see what's new without touching your files; pull (ideally --rebase on your own branch) to update them.
Go Deeper
- Git Basics · Git Commands & Usage
- Stash, Reset & Revert
- Git Errors & Troubleshooting
- Top 20 Git Interview Questions
