Common Git Mistakes

Last updated: April 13, 2025

Table of Contents

1. Introduction: Oops, I Did It Again!

Git is an incredibly powerful version control system, but with great power comes the potential for making mistakes. Whether you're a beginner or a seasoned developer, accidentally committing to the wrong branch, making a typo in a commit message, or needing to undo changes is a common experience. Fortunately, Git provides robust tools to recover from most common mishaps.

This guide covers some of the most frequent Git mistakes and provides practical steps on how to fix them. Remember to always understand what a command does before running it, especially those that modify history!

2. Mistake: Committed to the Wrong Branch

You made one or more commits, only to realize you were on main (or another incorrect branch) instead of your feature branch (e.g., feature/my-new-thing).

The Fix: Move the commits to the correct branch.

  1. Make sure your intended branch exists. If not, create it from the current state: 
    # Create the new branch pointing to the current commit
git branch feature/my-new-thing
  2. Reset the incorrect branch (e.g., main) back to where it should be (before your erroneous commits). Replace N with the number of commits you made incorrectly. 
    # Reset main back N commits, keeping the changes in your working directory
git reset HEAD~N --soft 
# OR if you haven't pushed and want to discard the commits from main entirely
# git reset HEAD~N --hard # Be careful with --hard!
    Alternatively, find the commit hash main *should* point to using git log and reset to that: 
    git reset <correct_main_commit_hash> --soft
  3. (If you used --soft reset and have changes staged) Clean up the staging area: 
    git reset HEAD
  4. Stash any uncommitted changes you want to keep but move: 
    git stash
  5. Checkout the correct branch: 
    git checkout feature/my-new-thing
  6. Apply the stashed changes (if you stashed any): 
    git stash pop
  7. If you used --soft reset in step 2, your changes are now in the working directory on the correct branch. Add and commit them: 
    git add .
git commit -m "Your commit message"
    If you made multiple commits initially, you might need to recommit them individually or combine them.

Now, your incorrect branch is back to its proper state, and your commits are on the correct feature branch.

3. Mistake: Forgot to Add Files to Last Commit

You made a commit, but realized you forgot to include one or more files, or missed a change in an existing file.

The Fix: Amend the last commit.

Important: Only do this if you haven't pushed the commit to a shared remote repository yet!

  1. Stage the missing file(s) or changes: 
    git add forgotten_file.txt
git add modified_file.js
  2. Amend the previous commit, adding the newly staged changes without changing the commit message: 
    git commit --amend --no-edit

Your last commit now includes the forgotten files/changes.

4. Mistake: Typo in the Last Commit Message

You just committed, but noticed a typo or error in the commit message.

The Fix: Amend the last commit message.

Important: Only do this if you haven't pushed the commit to a shared remote repository yet!

  1. Run the amend command: 
    git commit --amend
    This will open your default text editor with the previous commit message.
  2. Correct the message in the editor, save, and close the editor.
  3. Alternatively, provide the new message directly: 
    git commit --amend -m "Your corrected commit message"

The commit message is now fixed.

5. Mistake: Accidentally Deleted a Branch

You deleted a local branch (e.g., using git branch -d or git branch -D) but realized you still needed it.

The Fix: Use the reflog.

Git keeps a log of where HEAD and branch references have pointed (the reflog). You can usually find the last commit of the deleted branch there.

  1. View the reflog to find the last commit hash of the deleted branch: 
    git reflog
    Look for entries like checkout: moving from <deleted-branch-name> to <another-branch>. The commit hash associated with the <deleted-branch-name> state is what you need.
  2. Once you find the correct commit hash (e.g., a1b2c3d), recreate the branch pointing to that commit: 
    git checkout -b <deleted-branch-name> a1b2c3d

Your branch is now restored to its previous state.

6. Mistake: Committed Sensitive Data

You accidentally committed passwords, API keys, or other sensitive files.

The Fix (Complex & Requires Caution): Remove the data from history.

WARNING: Rewriting repository history is dangerous, especially if the repository is shared. It invalidates existing clones for collaborators. Always back up your repository before attempting this. Simple git commit --amend or git reset only works if the sensitive commit is the *very last* one and hasn't been pushed.

  1. Remove the file from your current working directory and stage the removal if it's still present. Add the file path to your .gitignore file to prevent re-committing it.
  2. Use a history rewriting tool: The recommended tool is git filter-repo (a replacement for the older, complex git filter-branch). BFG Repo-Cleaner is another option.

    Using git filter-repo (Example: Remove a file named secrets.yml):

    # Install git-filter-repo first if you haven't already
# (Follow instructions from its official repository)

# Run filter-repo to remove the file from all commits
git filter-repo --path secrets.yml --invert-paths

    Using BFG Repo-Cleaner (Example: Remove a file named secrets.yml):

    # Download bfg.jar first
# Create a bare clone (important!)
git clone --mirror git://example.com/my-repo.git

# Run BFG
java -jar bfg.jar --delete-files secrets.yml my-repo.git

# Go into the cleaned repo and run gc
cd my-repo.git
git reflog expire --expire=now --all && git gc --prune=now --aggressive

# Push the cleaned history (DANGEROUS - coordinate with team!)
# cd ..
# git push --force # Or preferably, coordinate and have everyone re-clone
  3. Invalidate Secrets: Crucially, any committed secrets (API keys, passwords) must be considered compromised. **Immediately revoke or change them.** Removing them from Git history does not make them secure again if they were ever public.
  4. Coordinate with Team: If the repo is shared, inform collaborators. They will likely need to re-clone or perform complex fetch/rebase operations. Force pushing (git push --force or --force-with-lease) will be necessary to update the remote repository with the rewritten history.

7. Mistake: Messy Commit History / Need to Rebase

Your feature branch has many small, "work-in-progress" commits, or it has fallen behind the main branch and has many merge commits cluttering the history.

The Fix: Interactive Rebase (git rebase -i).

Important: Avoid rebasing commits that have already been pushed and shared with others on a collaborative branch, as it rewrites history.

  1. Identify the base commit onto which you want to rebase or clean up commits *after*. This is often the commit where your feature branch diverged from the main branch (e.g., main or develop).
  2. Start the interactive rebase: 
    git rebase -i <base_commit_hash_or_branch_name>
# Example: Rebase current branch onto 'main'
git rebase -i main
  3. An editor will open listing the commits since the base. You can:
    • pick: Use the commit as is.
    • reword (or r): Edit the commit message.
    • edit (or e): Stop to amend the commit (change content and message).
    • squash (or s): Combine this commit with the previous one (merges changes and combines messages).
    • fixup (or f): Combine like squash, but discard this commit's message.
    • drop (or d): Delete the commit entirely.
    • Reorder lines to change commit order.
  4. Save and close the editor. Git will apply the changes. Resolve any conflicts that arise during the process. Use git rebase --continue after resolving conflicts, or git rebase --abort to cancel.

Interactive rebase is powerful for cleaning up local history before merging or creating a pull request.

8. Mistake: Force Pushed Over Shared Work

You used git push --force on a shared branch and overwrote commits made by others.

The Fix: Coordination and potentially restoring commits.

Prevention is key! Avoid using git push --force on shared branches. Use git push --force-with-lease instead, which checks if the remote branch has changed since your last fetch, preventing accidental overwrites.

  1. Stop! Inform your collaborators immediately.
  2. Find Lost Commits: Ask collaborators if they have the lost commits locally. They might be able to push them back up to a *new* branch. The reflog on the server (if accessible) or collaborators' local reflogs might also contain the lost commit hashes.
  3. Restore Commits: If someone has the commits, they can create a new branch from the lost commit hash and push it. Then you can merge or cherry-pick those commits back into the shared branch. 
    # Collaborator finds lost commit hash 'xyz123'
git checkout -b recovery-branch xyz123
git push origin recovery-branch

# On the main machine/branch
git fetch origin
git merge origin/recovery-branch # Or cherry-pick specific commits
  4. Rebase Your Work: Your local work might now need to be rebased onto the restored branch history using git pull --rebase before you can push again normally.

Recovering from a bad force push requires careful coordination.

9. Mistake: Lost Changes with git reset --hard

You ran git reset --hard and realized it discarded local changes (committed or uncommitted) that you actually needed.

The Fix: Check the reflog (immediately!).

git reset --hard moves the branch pointer and discards changes in the working directory and staging area. If the changes were *committed* before the reset, they might still be recoverable via the reflog.

  1. Immediately run git reflog: 
    git reflog
    Look for the commit hash representing the state *before* you ran git reset --hard.
  2. If you find the commit hash (e.g., a1b2c3d): You can restore your branch to that state: 
    git reset --hard a1b2c3d
    Or, create a new branch from that commit to inspect it without changing your current branch: 
    git checkout -b recovery-branch a1b2c3d
  3. If changes were uncommitted: Unfortunately, git reset --hard discards uncommitted changes permanently. Git doesn't track them. Your only hope might be filesystem recovery tools or IDE local history features (if available), but don't count on it. **Be very careful with git reset --hard!**

10. Conclusion: Git Happens

Making mistakes with Git is a normal part of the development process. The key is not to panic. Git provides powerful tools like --amend, rebase, reset, and especially the reflog, which act as safety nets for many common errors.

Understanding these recovery techniques can save you significant time and stress. Always try to understand what a command does before executing it, especially commands that modify history or involve force pushing. When in doubt, create backup branches or consult the extensive Git documentation.

11. Additional Resources