The 10 Git Pitfalls Frontend Devs Google Weekly — With a Quick-Reference Cheatsheet
After three years of using Git, I still Google Git commands at least twice a week. It's not that I don't know how to use it; it's that some operations only come up once a month, and I can never remember them. Last week, I ran into a merge conflict, and I reflexively opened my browser to search "how to undo a git merge"—after searching, I decided to compile these repeatedly-Googled operations into a quick reference sheet. From now on, I'll just look it up here.
Pitfall 1: Realizing the commit message is wrong after committing
This is the one I step into the most—typing too fast, hitting enter on git commit -m "fix" and only then realizing I should have written clearly what was changed.
# Change the most recent commit message (if it hasn't been pushed yet)
git commit --amend -m "fix: fix login page form validation logic"
Note: If it has already been pushed, amending will change the commit hash, and pushing again will require --force. If it's a branch for team collaboration, don't force push; use a new commit instead.
Pitfall 2: Realizing you've been working on the wrong branch for ages
After coding for an hour, you suddenly realize you've been making changes on main, not the feature branch.
# Stash the current changes
git stash
# Switch to the correct branch
git checkout feature/login
# Pop the stashed changes back out
git stash pop
git stash is like a "temporary pocket"—you put your uncommitted changes in it, switch branches, and then pull them back out.
Pitfall 3: Not knowing what to do when a merge conflict happens
This pitfall isn't about not knowing how to resolve the conflict, but rather wanting to back out halfway through resolving it.
# Abort this merge and return to the state before the merge
git merge --abort
If you've already resolved the conflicts but haven't committed yet and want to start over:
# Discard all conflict resolution changes
git checkout --conflict=merge .
Pitfall 4: Adding files you shouldn't have added
You accidentally ran git add . and added .env or node_modules.
# Remove from the staging area, but keep the local file
git reset HEAD .env
# If you've already committed, you need to delete it from history
git rm --cached .env
echo ".env" >> .gitignore
git commit -m "chore: remove accidentally committed .env file"
Prevention method: Set up .gitignore on day one of the project. Don't ask me how I know.
Pitfall 5: Wanting to undo the most recent commit (but keep the code)
After committing, you realize you missed a file, or you want to combine two commits into one.
# Undo the commit, but keep the code changes in the staging area
git reset --soft HEAD~1
# Undo the commit, keep the code changes but not in the staging area
git reset --mixed HEAD~1
# ⚠️ Undo the commit and discard the code changes (use with caution!)
git reset --hard HEAD~1
The differences between the three resets, in one table:
| Mode | Commit | Staging Area | Working Directory | Use Case |
|---|---|---|---|---|
--soft |
Undone | Kept | Kept | Want to reorganize commits |
--mixed |
Undone | Cleared | Kept | Want to re-select files to add |
--hard |
Undone | Cleared | Cleared | Don't want these changes at all |
Pitfall 6: Accidentally running git reset --hard and losing all your code
Everyone gets --hard wrong at least once in their career. Don't panic:
# View all operation records (including "deleted" commits)
git reflog
# Find the commit hash you want to recover, then
git reset --hard abc1234
reflog is Git's "undo button"; it records all your HEAD movement history, including resets. As long as git gc hasn't run, you can recover it within 30 days.
Pitfall 7: Wanting to see a previous version of a file
You can't remember what this file looked like last week and want to compare.
# View the content of a file at a specific commit
git show abc1234:src/utils/auth.js
# Compare the current version with the previous commit
git diff HEAD~1 -- src/utils/auth.js
# Compare a file's differences between two branches
git diff main..feature/login -- src/utils/auth.js
Pitfall 8: Wanting to grab just one commit from another branch
You don't want to merge the entire branch, just bring over the changes from one specific commit.
# cherry-pick: Apply the changes from a specified commit to the current branch
git cherry-pick abc1234
Common scenario: You fixed a bug on dev and want to bring that fix to the release branch, but you don't want to bring over other unfinished features from dev.
Pitfall 9: Having too many local branches and not knowing which ones can be deleted
You've opened a bunch of feature/xxx branches, forgot to delete them after merging, and git branch lists more than one screenful.
# View which branches have been merged into main (safe to delete)
git branch --merged main
# Delete merged local branches
git branch --merged main | grep -v "main" | xargs git branch -d
# Clean up remote-tracking branches that have been deleted on the remote
git fetch --prune
Pitfall 10: Push rejected with "non-fast-forward"
A colleague pushed before you, and your local branch is behind the remote.
# Option 1: Pull first, then push (will create a merge commit)
git pull
git push
# Option 2: Rebase then push (keeps a linear history, cleaner)
git pull --rebase
git push
Use whichever the team has agreed upon. I personally prefer --rebase because the git log is cleaner. But some teams feel merge commits clearly show "who merged what and when."
Quick Reference Sheet: Daily Frontend Git Operations
| Scenario | Command | Explanation |
|---|---|---|
| Change commit message | git commit --amend -m "new message" |
Use when not pushed |
| Worked on wrong branch | git stash → switch branch → git stash pop |
Temporary pocket |
| Abort a merge | git merge --abort |
When you want to back out halfway through conflict resolution |
| Undo add | git reset HEAD filename |
Remove from staging area |
| Undo commit, keep code | git reset --soft HEAD~1 |
Most commonly used |
| Recover hard-deleted code | git reflog → git reset --hard hash |
Undo button |
| View file history | git show hash:filepath |
|
| Grab just one commit | git cherry-pick hash |
Without merging the whole branch |
| Delete merged branches | git branch --merged main | xargs git branch -d |
Clean up regularly |
| Push rejected | git pull --rebase → git push |
Keep linear history |
A Practical Suggestion
If you, like me, often forget Git commands, add a few aliases to your ~/.bashrc or ~/.zshrc:
alias gs="git status"
alias gl="git log --oneline -10"
alias gco="git checkout"
alias gcm="git commit -m"
alias gst="git stash"
alias gsp="git stash pop"
No need to memorize commands, just memorize the abbreviations.
Finally
Even people who've used Git for ten years still Google it regularly. It's not because it's hard; it's because some operations really do only come up once a month. I'll bookmark this quick reference sheet myself and look it up directly when I forget.
What Git command do you Google the most? Add it in the comments, and I'll add it to the quick reference sheet.