Common Git Mistakes and How to Fix Them

Common Git Mistakes and How to Fix Them

Every Git user makes mistakes. Even experienced developers occasionally commit to the wrong branch, lose work to a hard reset, or push sensitive information. The difference between a beginner and an expert is not avoiding mistakes entirely, but knowing how to recognize them quickly and recover from them effectively. This guide covers the most common Git mistakes, why they happen, and exactly how to fix them when they do.

Understanding these mistakes and their fixes will save you hours of frustration and potentially prevent permanent data loss. Most Git mistakes are recoverable if you know the right commands. To understand these fixes properly, it is helpful to be familiar with Git core concepts, undoing changes, and basic Git workflow.

Mistake                    → Fix
─────────────────────────────────────────────────
Commit to wrong branch     → git reset, git cherry-pick
Forget to commit a file    → git commit --amend
Wrong commit message       → git commit --amend -m "new"
Accidental hard reset      → git reflog recovery
Push to wrong remote       → git push --force (carefully)
Commit secrets             → git filter-repo
Merge conflicts fear       → git merge --abort
Lose uncommitted work      → git fsck --lost-found

Mistake 1: Committing to the Wrong Branch

You are working on a feature branch, but you forget to switch and commit directly to main. Now your feature code is on the wrong branch. This is one of the most common Git mistakes.

# Step 1: Create a new branch at the current position (saves your commit)
git branch feature/your-feature

# Step 2: Reset main back to before your wrong commit
git reset --hard HEAD~1

# Step 3: Switch to your feature branch
git checkout feature/your-feature

# Your commit is now safely on the correct branch

If you have already pushed the wrong commit to the remote, you will need to force push after resetting. Use git push --force-with-lease instead of --force to avoid overwriting others' work.

Mistake 2: Forgetting to Add a File to Your Commit

You made a commit but forgot to include an important file. Now you have two commits where one would suffice, or your commit is incomplete.

# Stage the forgotten file
git add forgotten-file.js

# Amend the previous commit (adds the file to the existing commit)
git commit --amend --no-edit

# The forgotten file is now part of the original commit

If you have already pushed the commit, amending changes the commit hash. You will need to force push. Only do this if no one else has pulled your branch.

Mistake 3: Writing a Vague or Wrong Commit Message

You wrote "fix stuff" or made a typo in your commit message. Now the history is less useful than it should be.

# Change the message of the most recent commit
git commit --amend -m "feat(auth): add password reset functionality"

# For older commits, use interactive rebase
git rebase -i HEAD~3
# Change 'pick' to 'reword' for the commit you want to change
# Save and edit the message when prompted

Mistake 4: Accidental Hard Reset

You ran git reset --hard HEAD~3 and lost commits you still need. This feels catastrophic, but Git usually keeps a safety net.

# View the reflog to find the lost commits
git reflog

# Output shows something like:
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: Add important feature

# Recover by resetting back to the commit before the hard reset
git reset --hard def5678

# Or create a new branch at that commit
git branch recovered-branch def5678

The reflog keeps a history of where HEAD pointed for the last 90 days. As long as you act before garbage collection, your lost commits are almost always recoverable.

Mistake 5: Committing Secrets or Large Files

You accidentally committed an API key, password, or a 100MB video file. Removing it from the working directory is not enough; it is still in the history.

# For sensitive data, use git filter-repo (recommended)
pip install git-filter-repo

# Remove a file from entire history
git filter-repo --path secrets.env --invert-paths

# Or replace text in all commits
git filter-repo --replace-text <(echo 'old_password==>new_password')

# For large files, use BFG Repo-Cleaner
java -jar bfg.jar --strip-blobs-bigger-than 100M my-repo.git

# After cleaning, force push to remote
git push --force --all

If you committed a secret, also rotate it immediately. Removing it from history is not enough if it was ever exposed. Change the password or revoke the key.

Mistake 6: Pushing to the Wrong Remote

You pushed your feature branch to the main repository instead of your fork, or you pushed to the wrong remote entirely.

# If you pushed to the wrong branch on the same remote
git push origin --delete wrong-branch

# Then push to the correct branch
git push origin feature/correct-branch

# If you pushed to the wrong remote entirely
git push wrong-remote --delete feature/branch

# Add the correct remote if needed
git remote add correct-remote git@github.com:user/repo.git
git push correct-remote feature/branch

Mistake 7: Pulling Instead of Fetching

You used git pull and got unexpected merge commits or conflicts because you did not review the changes first.

# If you just pulled and want to undo the merge
git reset --hard ORIG_HEAD

# Better approach for the future: fetch then review
git fetch origin
git log main..origin/main   # See what changed
git diff main origin/main   # See actual changes
git merge origin/main       # Merge when ready

# Or configure pull to rebase instead
git config --global pull.rebase true

Mistake 8: Making Large, Unfocused Commits

You made a commit that changes ten unrelated files and fixes three different issues. Now the commit is hard to understand, revert, or cherry-pick.

# Unstage everything while keeping changes
git reset HEAD~

# Now stage changes in logical groups and commit separately
git add src/auth/     # Stage first logical group
git commit -m "feat(auth): add login endpoint"

git add tests/auth/   # Stage second logical group
git commit -m "test(auth): add login endpoint tests"

# If you already pushed, use interactive rebase to split
git rebase -i HEAD~1
# Mark commit as 'edit', then use git reset HEAD~ and commit separately

Mistake 9: Fear of Merge Conflicts

You avoid pulling or merging because you are afraid of conflicts. This only makes conflicts worse when they finally happen.

# If you started a merge and want to abort
git merge --abort

# If you are in the middle of a conflict
# Open conflicted files and look for:
# <<<<<<< HEAD (your changes)
# =======
# (their changes)
# >>>>>>> branch-name

# Edit to keep what you want, remove conflict markers
git add resolved-file.txt
git merge --continue

# Or use a merge tool
git mergetool

Mistake 10: Losing Uncommitted Work

You had unsaved changes in your working directory, and something happened that wiped them out.

# If you stashed but lost track
git stash list
git stash apply stash@{0}

# If you never staged or stashed, try git fsck
git fsck --lost-found

# Check .git/lost-found/other for dangling blobs
# These are file contents that Git still remembers

# For the future: stash frequently when switching contexts
git stash push -m "WIP: feature description"
git stash pop

Mistake 11: Not Using .gitignore Properly

Your repository is full of node_modules, .env files, IDE configurations, and build artifacts. This bloats the repo and risks exposing secrets.

# Add patterns to .gitignore
echo "node_modules/" >> .gitignore
echo ".env" >> .gitignore
echo ".DS_Store" >> .gitignore

# If files are already tracked, remove them from tracking
git rm --cached node_modules/ -r
git rm --cached .env
git commit -m "chore: remove ignored files from tracking"

# Now Git will ignore these files going forward

Mistake 12: Rebasing Shared Branches

You rebased a branch that others have already pulled. Now their local repositories diverge, and everyone is confused.

# On your local machine, before pulling again
git fetch origin
git reset --hard origin/branch-name

# If others already pulled, communicate and coordinate
# Everyone should run:
git fetch origin
git reset --hard origin/branch-name

# Prevention: Never rebase branches that others use
# Use merge for shared branches instead

Prevention Checklist

• Always check your current branch with git branch before committing.
• Use git status and git diff before every commit.
• Write commit messages using Conventional Commits format.
• Pull before pushing to avoid rejected pushes.
• Never rebase branches that others have pulled.
• Add secrets and large files to .gitignore before adding them.
• Use git stash when switching branches with uncommitted work.
• Remember that git reflog is your safety net.

Frequently Asked Questions

1. Can I recover a commit after git reset --hard?
   Yes. Use git reflog to find the commit hash and git reset --hard <hash> to restore it. Reflog keeps entries for about 90 days.
2. How do I undo a git push?
   Use git reset --hard HEAD~1 locally, then git push --force-with-lease. Only do this if no one else has pulled your changes.
3. What is the difference between git reset --soft, --mixed, and --hard?
   Soft resets move the branch pointer only. Mixed resets move the pointer and unstage changes. Hard resets move the pointer, unstage changes, and discard working directory changes.
4. How do I recover a deleted branch?
   Use git reflog to find the last commit hash of the deleted branch, then git branch recovered-branch <hash>.
5. What should I do if I committed to the wrong branch?
   Create a new branch at the current commit, reset the wrong branch back, then switch to the correct branch. The commit is preserved.
6. What should I learn next after common Git mistakes?
   After mastering these fixes, explore Git best practices, undoing changes in Git, Git workflows, and advanced Git commands for complete Git mastery.