The ultimate cheat sheet for fixing every Git mistake you will ever make.

🔍 Quick Find (What did you mess up?)

📝 Commits & Staging

• I committed directly to main/master
• I wrote a bad commit message
• I accidentally committed a secret/password!
• I accidentally committed a massive folder / ignored .gitignore
• I used git add . and staged things I shouldn't have
• I forgot to set my username/email

🌿 Branches & Merging

• I deleted a branch and need it back!
• I need to undo a hard reset (git reset --hard)
• I messed up a merge conflict
• I committed to the wrong branch
• I have a massive feature branch that is out of sync

☁️ Remote, Pushing & Pulling

• I force-pushed and overwrote my teammate's code
• I rebased a public branch by accident
• My push was rejected
• I pushed to the wrong remote (origin vs upstream)

🧰 Stashing & Tools

• I stashed my code and forgot where it went
• I need to clean up untracked files without deleting important stuff
• I don't know how to recover my code (Using Git Reflog)

🛠️ The 43 Mistakes (And How to Fix Them)

0. Not learning Git basics properly 📚

🚨 Risk: Missing foundational knowledge and making avoidable mistakes.

🛠️ Fix:

• Step 1: Read the official Git documentation and the Pro Git book.
• Step 2: Learn core commands like git status, git add, git commit, git branch, git merge, git rebase, and git reflog.
• Step 3: Practice on a small local repository before applying changes to shared production branches.

1. Committing directly to main/master without a branch 🚨

🚨 Risk: Immediate bugs in the production branch; hard to code review.

🛠️ Fix:

• Step 1: Undo the commit while keeping your changes using git reset HEAD~1 --soft.
• Step 2: Create and switch to a new feature branch using git checkout -b feature-branch.
• Step 3: Commit your changes safely to the new branch using git commit -m "message".

2. Vague or unhelpful commit messages 🤷‍♂️

🚨 Risk: Makes it impossible to understand the history of the project later.

🛠️ Fix:

• Step 1: If you haven't pushed yet, run git commit --amend.
• Step 2: Rewrite the message using a standard convention (e.g., Subject, Body, Ticket ID).
• Step 3: Save and close the editor to update the commit.

3. Committing secrets (API keys, passwords) 🔓

🚨 Risk: Massive security breach.

🛠️ Fix:

• Step 1: Immediately revoke or rotate the leaked API key on the provider's website.
• Step 2: Install git-filter-repo (pip install git-filter-repo or via system package).
• Step 3: Make a fresh mirror clone to get the full history using git clone --mirror https://github.com/user/repo.git.
• Step 4: Scrub the secret by running git filter-repo --replace-text <(echo 'PASSWORD==>REDACTED').
• Step 5: Force push the cleaned history using git push --force --tags --all.
• Step 6: Tell everyone on your team to re-clone the repository.

4. Not using .gitignore properly 🗑️

🚨 Risk: A noisy, cluttered repository and a massive history size.

🛠️ Fix:

• Step 1: Add the file or folder pattern (e.g., node_modules/) to your .gitignore file.
• Step 2: Remove the files from Git's memory by running git rm -r --cached <folder-name>.
• Step 3: Commit the removal (git commit -m "Clean up tracked files").

5. Large binary files in repo (images, videos) 🐘

🚨 Risk: Bloated repository; makes cloning the project incredibly slow.

🛠️ Fix:

• Step 1: Consider moving massive assets to external storage like S3. For remaining large files, install Git LFS using git lfs install.
• Step 2: Tell Git LFS to track specific files, e.g., git lfs track "*.mp4".
• Step 3: Run git add .gitattributes and commit it.
• Step 4: Commit your newly tracked large files as usual.

6. Force-pushing (git push --force) to shared branches 💥

🚨 Risk: Overwriting and permanently deleting your teammates' work.

🛠️ Fix:

• Step 1: Stop using git push --force.
• Step 2: Alias a safer alternative: echo "alias pushf='git push --force-with-lease'" >> ~/.bashrc && source ~/.bashrc.
• Step 3: Always use pushf (or --force-with-lease), which cancels the push if someone else added new commits.
• Step 4: Always communicate with your team before rewriting shared history.

7. Rebasing public/shared branches 🔄

🚨 Risk: Rewrites history that other developers are already depending on.

🛠️ Fix:

• Step 1: If you already rebased and pushed a public branch, warn your team so they can reset their local repos.
• Step 2: For future work, only run git rebase on local branches that you haven't pushed yet.
• Step 3: Use git merge when integrating changes into public, shared branches.

8. Not pulling/rebasing before pushing 🛑

🚨 Risk: Rejected pushes and messy merge conflicts.

🛠️ Fix:

• Step 1: Run git pull --rebase to fetch remote changes and apply your local commits on top of them.
• Step 2: If there are conflicts, resolve them in your code editor.
• Step 3: Run git rebase --continue to finish.
• Step 4: Safely push your code.

9. Mishandling merge conflicts ⚔️

🚨 Risk: Broken code, missing features, or lost changes.

🛠️ Fix:

• Step 1: Open the conflicting file in your code editor.
• Step 2: Look for the <<<<<<<, =======, and >>>>>>> conflict markers.
• Step 3: Carefully delete the markers and edit the code to combine both features correctly.
• Step 4: Run git add <file> and git commit to finalize the merge.

10. Long-lived feature branches diverging significantly 🕰️

🚨 Risk: Painful, massive merge conflicts when you finally try to merge.

🛠️ Fix:

• Step 1: Switch to your main branch and run git pull frequently.
• Step 2: Switch back to your feature branch.
• Step 3: Run git rebase main (or git merge main) to keep your branch up to date.
• Step 4: Repeat this process daily.

11. Not squashing or cleaning commits 🧼

🚨 Risk: A noisy history filled with "wip" and "fixing typo" commits.

🛠️ Fix:

• Step 1: Run git rebase -i HEAD~N (where N is the number of recent commits you want to clean).
• Step 2: In the editor, change the word pick to squash (or s) for the minor commits.
• Step 3: Save, then write a clean, single commit message for the merged work.

12. Using git add . indiscriminately 🎯

🚨 Risk: Accidentally staging unwanted files, secrets, or unfinished code.

🛠️ Fix:

• Step 1: Type git status first to see exactly what changed.
• Step 2: Use git add -p to review your changes chunk-by-chunk in the terminal.
• Step 3: Type y to stage a chunk or n to skip it.

13. Forgetting to set user.name and user.email 👤

🚨 Risk: Anonymous commits or wrong author info showing up on GitHub.

🛠️ Fix:

• Step 1: Run git config --global user.name "Your Name".
• Step 2: Run git config --global user.email "your.email@example.com".
• Step 3: Verify with git config --list.
• Step 4: For per-repo overrides, run git config user.email "work@email.com" inside the project folder.

14. Committing generated files 🏭

🚨 Risk: Constant merge conflicts and unnecessary repository bloat.

🛠️ Fix:

• Step 1: Identify the generated folders (e.g., dist/, build/).
• Step 2: Add those folders to your .gitignore file.
• Step 3: Remove them from Git using git rm -r --cached <folder>.
• Step 4: Rely on your CI/CD pipeline to generate these files automatically.

15. Using merge to clean up local history 🧹

🚨 Risk: A cluttered, hard-to-read commit graph.

🛠️ Fix:

• Step 1: While on your feature branch, run git rebase main instead of git merge main.
• Step 2: Resolve any conflicts as they appear.
• Step 3: Enjoy a clean, straight, linear history before you open a Pull Request.

16. Incorrectly resolving history with git reset --hard 💀

🚨 Risk: Permanent data loss if you haven't committed or stashed your files.

🛠️ Fix:

• Step 1: Do not panic. Run git reflog.
• Step 2: Find the commit hash (e.g., HEAD@{1}) from right before you did the hard reset.
• Step 3: Run git reset --hard <hash> to travel back in time and restore your files.

17. Deleting branches without checking remote state 👻

🚨 Risk: Accidentally removing unmerged work.

🛠️ Fix:

• Step 1: If already deleted, run git reflog to find the last commit hash of that branch.
• Step 2: Run git checkout -b <deleted-branch-name> <hash> to bring it back from the dead.
• Step 3: In the future, verify the PR is merged on GitHub before running branch delete commands.

18. Overusing git stash and forgetting changes 📦

🚨 Risk: Lost or forgotten work that gets buried over time.

🛠️ Fix:

• Step 1: Stop using plain git stash.
• Step 2: Use git stash save "Descriptive message".
• Step 3: Run git stash list occasionally to review your saved work.
• Step 4: Run git stash pop stash@{n} to apply a specific stash.

19. Not using branches for experiments 🧪

🚨 Risk: Messing up your working code on the main branch.

🛠️ Fix:

• Step 1: Run git checkout -b experimental-feature.
• Step 2: Code and commit without fear.
• Step 3: If the experiment fails, switch back to main and delete the branch (git branch -D experimental-feature).

20. Ignoring git reflog when recovering lost commits 🕰️

🚨 Risk: Assuming your lost commits are permanently gone.

🛠️ Fix:

• Step 1: Open your terminal and type git reflog.
• Step 2: Scroll through the chronological list of every single action you took recently.
• Step 3: Copy the hash of the state you want to return to.
• Step 4: Run git checkout <hash> or git reset --hard <hash> to recover it.

21. Bad use of git cherry-pick 🍒

🚨 Risk: Duplicate commits or out-of-order changes that break the build.

🛠️ Fix:

• Step 1: If a cherry-pick causes massive conflicts, run git cherry-pick --abort.
• Step 2: To cherry-pick safely, find the exact commit hash you need.
• Step 3: Switch to your target branch.
• Step 4: Run git cherry-pick <hash>.

22. Creating commits that break the build 🚧

🚨 Risk: Breaking the main branch for everyone else.

🛠️ Fix:

• Step 1: Set up automated pre-commit checks on your server (GitHub Actions).
• Step 2: Install a local pre-commit tool (Husky or Python pre-commit).
• Step 3: Configure the tool to automatically run your linters and test suite locally.
• Step 4: Only use git commit --no-verify as an absolute emergency escape hatch.

23. Forgetting to pull submodule updates 🧩

🚨 Risk: Submodules get stuck at the wrong commits.

🛠️ Fix:

• Step 1: After pulling new code, check if your app fails to build.
• Step 2: Run git submodule update --init --recursive to fetch the correct submodule data.
• Step 3: Create an alias for this command if you use submodules frequently.

24. Not using tags for releases 🏷️

🚨 Risk: Hard to identify which commit matches which production release.

🛠️ Fix:

• Step 1: Checkout the exact commit deployed to production.
• Step 2: Run git tag -a v1.0.0 -m "Release version 1.0.0".
• Step 3: Run git push origin v1.0.0 (or git push --tags).

25. Mixing commit types (WIP + feature + fix) 🍲

🚨 Risk: Makes it impossible to revert a bug without reverting the new feature.

🛠️ Fix:

• Step 1: Run git reset HEAD~1 --mixed to unstage the massive commit.
• Step 2: Use git add to selectively stage only the files related to the bug fix.
• Step 3: Commit the fix.
• Step 4: Stage the remaining files and commit the feature separately.

26. Misunderstanding git pull vs git fetch 📥

🚨 Risk: Accidental merges that mess up your working directory.

🛠️ Fix:

• Step 1: Stop running git pull blindly.
• Step 2: Run git fetch origin to download remote data safely.
• Step 3: Check the incoming changes using git log main..origin/main.
• Step 4: If everything looks good, manually run git merge origin/main.

27. Keeping secrets in history after removing the file 🕵️

🚨 Risk: The secret is still accessible in older commits.

🛠️ Fix:

• Step 1: Assume the secret is compromised and immediately change it on the platform.
• Step 2: Install git-filter-repo.
• Step 3: Make a fresh mirror clone: git clone --mirror https://github.com/user/repo.git.
• Step 4: Scrub the secret: git filter-repo --replace-text <(echo 'PASSWORD==>REDACTED').
• Step 5: Force push: git push --force --tags --all.

28. Not configuring line endings properly (CRLF vs LF) 📝

🚨 Risk: Noisy diffs where Git thinks you rewrote the entire file.

🛠️ Fix:

• Step 1: Create a .gitattributes file in the root of your repository.
• Step 2: Add * text=auto eol=lf to enforce LF line endings.
• Step 3: Run git add --renormalize . to fix any existing files.
• Step 4: Commit the updated files and .gitattributes.

29. Committing to the wrong branch by accident 🛤️

🚨 Risk: Commits end up in unintended places.

🛠️ Fix:

• Step 1: Run git reset HEAD~1 --soft to undo the commit but keep files staged.
• Step 2: Run git stash to save the changes safely.
• Step 3: Switch to the correct branch using git checkout correct-branch.
• Step 4: Run git stash pop, then git commit.

30. Using git merge --squash and losing metadata 📉

🚨 Risk: Losing the original commit authorship and message history.

🛠️ Fix:

• Step 1: Ensure the Pull Request description contains necessary context.
• Step 2: Run git merge --squash <branch>.
• Step 3: When Git prompts you for the commit message, manually list the co-authors.

31. Overwriting remote changes with force push after rebasing 🌪️

🚨 Risk: Collaborators' incoming commits get erased from GitHub.

🛠️ Fix:

• Step 1: If you erased code, ask your teammate to find their lost commit in git reflog.
• Step 2: Have them push that specific commit back up.
• Step 3: Alias your terminal to use git push --force-with-lease instead of --force.

32. Ignoring commit granularity for atomic changes 🧱

🚨 Risk: Hard to bisect bugs or revert changes safely.

🛠️ Fix:

• Step 1: Break your task down into logical steps before coding.
• Step 2: Write code for one small piece.
• Step 3: Commit that piece immediately.
• Step 4: Move on to the next piece and repeat.

33. Confusing git reset modes (--soft, --mixed, --hard) 🎛️

🚨 Risk: Unintended staging of files or complete data loss.

🛠️ Fix:

• Step 1: Use --soft to undo a commit but keep files actively staged.
• Step 2: Use --mixed (default) to undo a commit and unstage the files, keeping code in editor.
• Step 3: Use --hard ONLY to completely destroy the local code and return to a previous state.

34. Pushing to the wrong remote (origin vs upstream) 🌍

🚨 Risk: Accidental pushes to a company's main repo instead of a personal fork.

🛠️ Fix:

• Step 1: Verify your remotes by running git remote -v.
• Step 2: Never type just git push.
• Step 3: Always specify the remote and branch: git push origin feature-branch.

35. Not using git status often 🔎

🚨 Risk: Total uncertainty about your repository state.

🛠️ Fix:

• Step 1: Make it a reflex to type git status before you run git add.
• Step 2: Type git status again before git commit.
• Step 3: Type git status one last time before git push.

36. Not cleaning up stale branches 🍂

🚨 Risk: Clutter, confusion, and a massive list of branches.

🛠️ Fix:

• Step 1: Run git fetch -p && git branch -vv | grep gone to track down pruned branches.
• Step 2: Review the list of dead branches.
• Step 3: Delete them locally using git branch -d <branch-name>.

37. Relying solely on git revert without understanding context ⏪

🚨 Risk: A revert might not apply cleanly to future history.

🛠️ Fix:

• Step 1: Run git revert <hash>.
• Step 2: Do not push immediately. Run your local server and test suite.
• Step 3: Ensure the reversion didn't break surrounding code before pushing.

38. Performing interactive rebase incorrectly 🔀

🚨 Risk: Accidental dropping or deleting of important commits.

🛠️ Fix:

• Step 1: Create a backup branch by running git branch backup-branch.
• Step 2: Perform your git rebase -i.
• Step 3: If you mess up, simply run git reset --hard backup-branch to safely start over.

39. Committing with the wrong author 🥸

🚨 Risk: Incorrect credit, and CI checks might fail.

🛠️ Fix:

• Step 1: If it's just the last commit, run git commit --amend --author="Name <email@example.com>".
• Step 2: If multiple commits, use git rebase -i to edit the specific commits.
• Step 3: Check your config (git config user.email) to prevent it happening again.

40. Using git clean without preview (-n) 🧨

🚨 Risk: Deleting untracked files accidentally that you actually needed.

🛠️ Fix:

• Step 1: Always run git clean -n -d first. This is a "dry run".
• Step 2: Review the list of untracked files Git prints.
• Step 3: Once you are 100% sure, run git clean -f -d to forcefully delete them.

41. Ignoring pre-commit hooks locally 🚫

🚨 Risk: Pushing sloppy code and wasting your team's time.

🛠️ Fix:

• Step 1: Read your project's setup documentation.
• Step 2: Run the required command (e.g., npm install) to enable hooks.
• Step 3: Fix the formatting/linting errors locally instead of bypassing with --no-verify.

42. Not making backups before history-rewriting operations 🪂

🚨 Risk: Irreversible mistakes when learning complex Git commands.

🛠️ Fix:

• Step 1: Identify the dangerous command you are about to run.
• Step 2: Create a safety net by running git branch safety-net.
• Step 3: Run the command. If it destroys your code, git checkout safety-net and try again.

43. Assuming git commands are destructive without checking the reflog 🚑

🚨 Risk: Unnecessary panic, crying, or giving up.

🛠️ Fix:

• Step 1: Stop panicking when code disappears.
• Step 2: Remember that Git almost never deletes commits instantly; it just hides them.
• Step 3: Run git reflog, follow the breadcrumbs, and rescue your code.

Created for the open-source community. Star the repo if this saved your code! ⭐