Undoing Mistakes in Git: Reset, Revert & Restore

🔥 Your git log is a horror story. Here's how to fix it. We've all seen this: fix asdf wip changed stuff update 6 months later — you have ZERO idea what happened or why. Here's the fix 👇 🧱 The anatomy of a great commit: <type>(scope): short imperative summary under 50 chars Types to know: → feat — new feature → fix — bug fix → refactor — code cleanup, no behavior change → docs — documentation only → test — adding or fixing tests → chore — build tools, deps, config ⚡ 5 Golden Rules: 1. Use the imperative mood Write "Add login page" not "Added login page" Think: "This commit will..." 2. Keep the subject under 50 characters It fits in git log, GitHub PRs, and terminal output perfectly 3. Separate subject from body with a blank line The body explains the WHY — not the what 4. Reference tickets and issues End with Closes #42 or Fixes #101 Links your commit to its reason for existing 5. One logical change per commit Atomic commits = easier to revert, review, and blame 📋 Quick template: feat(auth): add remember-me cookie support Users requested persistent sessions across browser restarts. Implemented a secure HttpOnly cookie with 30-day expiry. Closes #87 💡 Your commit history is documentation. Your team reads it. Your future self reads it. Make it count. Save this post 🔖 and share it with a dev who writes fix commits. What's the worst commit message you've ever seen? Drop it below 👇 #Git #CleanCode #DevTips #SoftwareEngineering #WebDevelopment #100DaysOfCode #Programming #OpenSource #TechTips #CodeQuality

🚀 Today I learned: How to revert only specific files from a bad Git commit Earlier today, I made a mistake while working on a feature branch — I accidentally overwrote 31 important "workflow.json" files across two folders. The tricky part? I also had valid changes in the same branch that I needed to keep. A normal "git revert" would undo everything - good and bad. That’s when I discovered a much cleaner approach: a surgical revert that restores only the files you choose. Here’s the simple workflow I followed 👇 🔍 1. Find commits that touched the files git log --oneline -- 'path/to/folder/**/file.json' This filters history so you can quickly spot where things went wrong. 👀 2. Peek at file content from any commit git show <commit-id>:path/to/file.json No checkout needed — just inspect the file as it existed in the past. 📂 3. List exactly which files a bad commit changed git diff-tree --no-commit-id --name-only -r <bad-commit> -- 'path/**/*.json' This gave me a precise list of the 31 affected files. ♻️ 4. The magic command — restore only those files git checkout <good-commit-or-branch> -- file1 file2 file3 ... This pulls back only the selected files — everything else stays untouched. ✨ ✅ 5. Verify before committing git status --short git diff --cached I used to worry about “messing up Git,” but moments like this made me realize - Git is actually very forgiving when you know the right tools. If you're learning Git, this is a skill that will save you hours someday. #Git #SoftwareEngineering #LearningInPublic #DeveloperTips #VersionControl

𝟱 𝗮𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗚𝗶𝘁 𝗰𝗼𝗺𝗺𝗮𝗻𝗱𝘀 𝗜 𝘄𝗶𝘀𝗵 𝗜 𝗹𝗲𝗮𝗿𝗻𝗲𝗱 𝗲𝗮𝗿𝗹𝗶𝗲𝗿. Most engineers know add, commit, push. These 5 are the ones that actually save you when things go sideways. 𝟭. 𝗴𝗶𝘁 𝗿𝗲𝗳𝗹𝗼𝗴 — 𝘆𝗼𝘂𝗿 𝘀𝗮𝗳𝗲𝘁𝘆 𝗻𝗲𝘁 Accidentally did git reset --hard? Reflog keeps a record of every HEAD move for ~90 days. git reset --hard HEAD@{1} and you're back. 𝘕𝘰𝘵𝘩𝘪𝘯𝘨 𝘪𝘴 𝘵𝘳𝘶𝘭𝘺 𝘭𝘰𝘴𝘵. 𝟮. 𝗴𝗶𝘁 𝗿𝗲𝗯𝗮𝘀𝗲 -𝗶 — 𝗰𝗹𝗲𝗮𝗻 𝗵𝗶𝘀𝘁𝗼𝗿𝘆 𝗯𝗲𝗳𝗼𝗿𝗲 𝗮 𝗣𝗥 10 "WIP" commits, 3 typo fixes, 2 "oops" commits. Embarrassing. git rebase -i HEAD~10 — squash, reword, or drop commits before anyone reviews. 𝟯. 𝗴𝗶𝘁 𝗯𝗶𝘀𝗲𝗰𝘁 — 𝗯𝗶𝗻𝗮𝗿𝘆 𝘀𝗲𝗮𝗿𝗰𝗵 𝗳𝗼𝗿 𝗮 𝗯𝘂𝗴 500 commits. Something broke. No idea when. git bisect start → mark good and bad commits → Git finds the culprit in ~9 steps. Fully automated: git bisect run pytest tests/ 𝟰. 𝗴𝗶𝘁 𝘄𝗼𝗿𝗸𝘁𝗿𝗲𝗲 — 𝘁𝘄𝗼 𝗯𝗿𝗮𝗻𝗰𝗵𝗲𝘀, 𝗻𝗼 𝘀𝘁𝗮𝘀𝗵𝗶𝗻𝗴 git worktree add ../hotfix hotfix/auth Full second working copy of the same repo, different branch. No stash, no context-switch chaos. 𝟱. 𝗴𝗶𝘁 𝗰𝗵𝗲𝗿𝗿𝘆-𝗽𝗶𝗰𝗸 --𝗻𝗼-𝗰𝗼𝗺𝗺𝗶𝘁 Apply one commit from another branch — but inspect it before it lands. git cherry-pick --no-commit a3f9b2c → review with git diff --staged → commit when satisfied. 𝗴𝗶𝘁 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝘀𝗮𝘃𝗲 𝗯𝘂𝘁𝘁𝗼𝗻. 𝗜𝘁'𝘀 𝗮 𝘁𝗶𝗺𝗲 𝗺𝗮𝗰𝗵𝗶𝗻𝗲. Learn the power commands and you'll never fear a bad commit again. #git #devtools #softwaredevelopment #versioncontrol #engineeringlife

Most engineers learn 4-5 Git commands (add, commit, push, pull, status) and think they know git. Well, it's enough to ship code and also enough to get into trouble 😉 At least learn the ones below to stay safe --> git log --oneline --graph --all Shows the entire branch history as a tree. Whole repo, one screen. --> git reflog Remembers every action for 90 days. Deleted a branch? Reset to the wrong commit? Force-pushed over your work? Reflog brings it back. --> git stash Parks uncommitted work without a commit. Switch branches, come back, pop it. No fake "WIP" commits in your history. --> git bisect Turns debugging into binary search. Tell it a working commit and a broken one. Find the bad commit across hundreds of changes in five steps. --> git blame Finds the commit, the PR, and the context behind a decision someone made eighteen months ago. --> git cherry-pick Pulls a single commit from one branch into another. Hotfix on main you need on staging? One command, no baggage. --> git diff --staged Shows exactly what's about to be committed. Catches debug prints and hardcoded keys before they ship. --> git restore --staged Unstages a file without losing your changes. The fix for "I added the wrong file." --> git switch Modern replacement for git checkout when moving between branches. Cleaner and harder to misuse. --> git clean -fd Deletes untracked files and directories. The nuclear option for a messy working tree. --> git commit --amend Rewrites your last commit. Forgot a file? Bad message? Fix it before anyone sees. Save it. Share it. and Like this post as a thank you😀😀

Every time I started a new project with Claude Code, I watched myself re-derive the same decisions. Which things belong in a reusable skill. What code should never touch. When the agent should stop and ask. So I encoded it. One CLAUDE.md file. Versioned in git. Symlinked into the path Claude Code auto-loads on every session. Plus a companion skill that runs periodically to audit the file for bloat — every line has to pass a deletion test: would the agent's behavior degrade noticeably if I cut this? If no, it goes. Sync across machines with one git pull. Sync across time with commit history. Most teams patch this with ad-hoc prompts, README fragments, Slack pins. They drift and contradict each other within a month. I've started calling this principles as code. It's how judgment compounds across sessions, projects, and collaborators — instead of evaporating between them. The craft isn't the prompt. It's the versioned layer underneath.

Most devs know 5 git commands. Then production diverges at 3 a.m. and those 5 aren't enough. Here are 10 I actually reach for every week. 1. git reflog Your undo button. rebase, reset, force-push — reflog remembers. 2. git log --oneline --graph --all See your branch topology without opening a GUI. 3. git commit --amend --no-edit Fix the last commit. Keep the message. 4. git stash push -m "wip: auth on /users" Stash with context. Future You will thank you. 5. git blame -L 42,58 services/auth.py Blame a line range, not the whole file. 6. git rebase -i HEAD~5 Clean your PR history before review, not during it. 7. git cherry-pick <sha> Port one commit across branches. No full-branch merge. 8. git worktree add ../hotfix origin/main Two branches checked out at once. Zero context switch. 9. git bisect start HEAD v1.2 Binary-search your way to the commit that broke prod. 10. git push --force-with-lease The safe force push. Pair with --force-if-includes on git 2.30+. None of these are niche. They are the difference between a 10-minute fix and a 2-hour war room. Save this before your next git emergency. Which one saved you first — and what was the incident? One command, one sentence. #Git #SoftwareEngineering #DeveloperTips #CodingTips

Ever needed to switch branches… but your code isn’t ready to commit? 👀 That’s where git stash helps. It saves your current work (staged + modified tracked changes) and resets everything back to HEAD, so you can safely switch branches without committing incomplete code. Your stashes are stored like a stack (stash@{0} is the latest), and you can reuse them anytime. By default, only tracked files are saved: Add untracked files → git stash push -u Add ignored files → git stash push -a When you’re ready to continue: git stash apply → bring changes back (keep stash) git stash pop → bring changes + remove stash Need a specific one? git stash apply stash@{N} Want your staged changes back too? git stash apply --index git stash pop --index Manage everything easily: Save → git stash push -m "message" View → git stash list Inspect → git stash show -p stash@{N} Delete → git stash drop stash@{N} or git stash clear Think of it as putting your work on pause without losing a thing. 👉 Follow for more practical dev tips! #Git #GitHub #WebDevelopment #DevTips #Developers #Syncfusion

Five commands for when things go wrong in Git: 1. See your recent history including the disaster: $ git reflog Output: a1b2c3d HEAD@{0}: commit: Add dashboard feature e5f6a7b HEAD@{1}: reset: moving to HEAD~20 ← the mistake 8f3e9a2 HEAD@{2}: commit: Add notification system ← what you want 2. Recover to any point in that history: $ git checkout -b recovery HEAD@{2} 3. Recover a deleted branch: Find the last commit on the deleted branch in reflog, then: $ git checkout -b recovered-branch <hash> 4. See everything not referenced by any branch: $ git fsck --lost-found 5. Check how long the reflog goes back: $ git config gc.reflogExpire # Default: 90 days The limits: ❌ Work that was never committed (truly gone) ❌ Stash dropped explicitly ❌ Objects after reflog expiry For everything else within 90 days: check reflog first. If a colleague says "I lost a week of work in Git" — ask them if they tried git reflog before accepting defeat. 📌 Bookmark this. Share with your team. Save this post. The day will come when you need it. #Git #DevTips #SoftwareDevelopment #Programming #TechTips

POST 3 of 10 — Core Concepts (The Mental Model) This mental model is what finally made Git click for me. Most people jump straight into commands without understanding what’s actually happening. Don’t be that person. Git has 4 zones — and files move through them in order: Working Directory → Staging Area → Local Repository → GitHub (your files) → (git add) → (git commit) → (git push) Think of Git like mailing a package 📦 📁 Working Directory — items on your desk 🎯 Staging Area — items placed in the box (git add) 💾 Commit — the sealed box with a label (your message) ☁️ Push — shipping the box to GitHub’s warehouse POST 4 of 10 — Essential Commands You don’t need to memorize 100 Git commands. You need these 15. That’s it. 📊 See what’s happening: git status # run this constantly git log --oneline # compact commit history git diff # line-by-line changes 💾 Save your work: git add . # stage everything git add file.py # stage one file git commit -m "msg" # save a snapshot ☁️ Sync with GitHub: git push # upload commits git pull # get latest changes git clone <url> # copy a repo 🌿 Work with branches: git checkout -b feature-name # create + switch git checkout main # go back to main git merge feature-name # merge changes git branch -d feature-name # delete merged branch 🆘 Oops, undo: git restore file.py # discard file changes git revert HEAD # undo last commit safely The most important command? git status Run it before and after every Git command until it’s muscle memory. #Git #GitHub #CodingTips #Programming #DataScience

𝗧𝗵𝗲 𝗖𝗹𝗮𝗎𝗱𝗲 𝗖𝗼𝗱𝗲 𝗗𝗲𝗯𝗮𝗸𝗲: 𝗚𝗨𝗜 𝗩𝗦 𝗧𝗲𝗿𝗺𝗶𝗻𝗮𝗹 I used Claude Code in the terminal for a while. It worked well with my JetBrains IDE and git branches. Then Anthropic released the GUI preview with the Opus model. I thought it would be great. But it was not. The GUI does not work in your project directory. It creates a separate git worktree. This causes issues with your IDE and git branches. You can use a workaround with VSCode, but it does not work for JetBrains users. The GUI also has issues with git worktrees. Your .env file and local config are not included. This means your app will not run. I use zsh, but the GUI only supports bash. This means my shell environment and aliases do not work. The GUI solves some problems, like session persistence and no compacting. But you can get these benefits with the terminal version and the Opus model. The terminal version gives you: - Opus-level reasoning - Your IDE working normally - Your .env and gitignored files intact - Your zsh config and PATH - Clean git workflow You can run Opus in the terminal and keep your workflow. The GUI preview is not necessary. It creates problems for developers with established workflows. The real benefits come from the Opus model, not the GUI. Source: https://lnkd.in/gMf2a9m2 Optional learning community: https://t.me/GyaanSetuAi