5 Git Commands to Save Your Sanity

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

🔥 Undoing Mistakes in Git: Reset, Revert & Restore — Explained Simply Made a bad commit? Staged the wrong file? We've all been there. Here's your go-to cheat sheet for undoing things in Git 👇 ↩ git reset — Rewrite History (Local Only) Moves your branch pointer back to a previous commit. (: --soft → keeps your changes staged (: --mixed → keeps changes unstaged (default) (: --hard → deletes everything permanently ⚠️ Never use on shared/public branches — it rewrites history. ⊘ git revert — The Safe Undo Creates a new commit that reverses a past one. (: Doesn't touch history (: Safe for shared & production branches (: Keeps a full audit trail Golden rule: When in doubt, revert — don't reset. ✦ git restore — Per-File Undo Discard changes at the file level — no history impact at all. (: git restore <file> → discard unstaged edits (: git restore --staged <file> → unstage a file Cleaner replacement for the old git checkout -- <file>. 📌 Quick Guide: Situation Command Undo last commit (keep changes) git reset --soft HEAD~1 Undo last commit (delete changes) git reset --hard HEAD~1 Undo a pushed commit safely git revert <hash> Discard file edits git restore <file> Unstage a file git restore --staged <file> Save this post for the next time Git has you panicking 🚑 Which of these do you use most? Drop it below 👇 #Git #DevTips #SoftwareEngineering #Programming #100DaysOfCode #WebDevelopment #OpenSource #CodeNewbie #TechEducation #VersionControl

“𝐃𝐨𝐧’𝐭 𝐜𝐨𝐧𝐭𝐫𝐢𝐛𝐮𝐭𝐞 𝐭𝐨 𝐭𝐡𝐞 𝐫𝐞𝐩𝐨 𝐰𝐢𝐭𝐡 𝐝𝐢𝐫𝐭𝐲 𝐜𝐨𝐦𝐦𝐢𝐭𝐬.” Early in my career, I rushed a fix. My PR looked like this: • Initial commit • Typo fix • Debugging • Updated README 1 • Updated README 2 • Plz work • Final FINAL fix It got clumsy and junky. The lesson? 𝐌𝐞𝐬𝐬𝐲 𝐡𝐢𝐬𝐭𝐨𝐫𝐲 = 𝐦𝐞𝐬𝐬𝐲 𝐭𝐡𝐢𝐧𝐤𝐢𝐧𝐠 (at least from the outside). 𝐂𝐥𝐞𝐚𝐧 𝐜𝐨𝐦𝐦𝐢𝐭𝐬 𝐛𝐮𝐢𝐥𝐝 clarity and make it easier to update features in the future. Commands every serious developer should master: → 𝐠𝐢𝐭 𝐬𝐭𝐚𝐬𝐡 Temporarily save your work to switch tasks instantly. → 𝐠𝐢𝐭 𝐜𝐨𝐦𝐦𝐢𝐭 --𝐚𝐦𝐞𝐧𝐝 Fix your last commit without adding noise. → 𝐠𝐢𝐭 𝐫𝐞𝐛𝐚𝐬𝐞 -𝐢 𝐇𝐄𝐀𝐃~𝐧 Clean, reorder, or squash commits into one clear story. → 𝐠𝐢𝐭 𝐜𝐡𝐞𝐫𝐫𝐲-𝐩𝐢𝐜𝐤 Move only the changes you need (perfect for hotfixes). → 𝐠𝐢𝐭 𝐫𝐞𝐟𝐥𝐨𝐠 Your safety net — recover “lost” commits anytime. → 𝐠𝐢𝐭 𝐫𝐞𝐬𝐞𝐭 --𝐬𝐨𝐟𝐭 𝐇𝐄𝐀𝐃~𝟏 Undo last commit, keep your changes ready. → 𝐠𝐢𝐭 𝐝𝐢𝐟𝐟 Review changes before you embarrass yourself. The truth? Good developers write code. 𝐆𝐫𝐞𝐚𝐭 𝐝𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 𝐩𝐫𝐞𝐬𝐞𝐧𝐭 𝐢𝐭 𝐜𝐥𝐞𝐚𝐧𝐥𝐲. Do you clean your commit history — or ship the chaos? 👇 #BackendEngineering #Git #CleanCode #DeveloperMindset #Coding #CodingIsTherapy

🔥 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

git bisect is great. Until your bug doesn't reproduce consistently. Flaky tests, race conditions, nondeterministic failures. Standard bisect needs the bug to show up every single time. If it doesn't, you're stuck running each commit 10 times "just to be sure." 𝗘𝗻𝘁𝗲𝗿 𝗴𝗶𝘁 𝗯𝗮𝘆𝘀𝗲𝗰𝘁 A Bayesian version of git bisect, built for bugs that don't reproduce deterministically. 𝗛𝗼𝘄 𝗶𝘁 𝘄𝗼𝗿𝗸𝘀 Instead of binary search (which assumes pass/fail is reliable), baysect uses Bayesian probability to handle uncertain outcomes. 👉🏽 Each test result updates a probability distribution across commits 👉🏽 The tool picks the next commit to test based on maximum information gain 👉🏽 Fewer test runs needed to pinpoint the problematic commit 👉🏽 Works even when a test fails 30% of the time on a good commit With slow test suites, this saves hours. You don't need to rerun each commit until you're "confident enough." The math handles the confidence for you. 𝗪𝗵𝗲𝗻 𝘁𝗼 𝘂𝘀𝗲 𝗶𝘁 👉🏽 Flaky test suites where bugs appear intermittently 👉🏽 Race conditions that only show up under load 👉🏽 Any regression where you can't get a clean pass/fail signal Even for deterministic bugs where you don't have precise reproduction steps, baysect can help narrow things down faster than manually guessing which commits to check. If you've ever spent a Friday afternoon running git bisect on a test that fails "sometimes," this is for you. 𝘏𝘰𝘸 𝘥𝘰 𝘺𝘰𝘶 𝘩𝘢𝘯𝘥𝘭𝘦 𝘧𝘭𝘢𝘬𝘺 𝘣𝘶𝘨𝘴 𝘪𝘯 𝘺𝘰𝘶𝘳 𝘤𝘰𝘥𝘦𝘣𝘢𝘴𝘦?

Stop the "Stash & Switch" madness. 🛑 We’ve all been there: You’re deep in a feature, your workspace is a mess of half-finished logic, and suddenly... a critical bug hits production. Most devs reach for git stash. Some make a messy "WIP" commit. But there’s a better way that most people ignore: Git Worktree. Instead of flipping a single folder between branches, Git Worktree lets you "check out" multiple branches into separate folders simultaneously, all linked to the same local repo. Why is this a game-changer? ✅ Zero Context Switching: Keep your feature code open in one VS Code window and your hotfix in another. No stashing required. ✅ Parallel Testing: Run a heavy test suite or build process on one branch while you keep coding on the other. ✅ Code Reviews: Need to test a teammate's PR? Open it in a new worktree without touching your current progress. ✅ No More npm install Loops: If branches have different dependencies, worktrees keep their respective node_modules intact. No more re-installing every time you switch. The Magic Command: git worktree add ../hotfix-folder hotfix-branch It’s one of those "once you know it, you can't go back" tools. Are you still stashing, or have you made the switch to Worktrees? Let’s hear your workflow hacks in the comments! 👇 #Git #WebDevelopment #SoftwareEngineering #DevOps #ProgrammingTips #Efficiency

🚀 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

What actually happens between git push and your app going live in production? Most engineers know CI/CD as a concept. Very few know exactly what fires, when, and why. Here is the complete flow — step by step: STEP 1 — Code commit Developer pushes to a feature branch. A webhook fires immediately. Your pipeline wakes up. STEP 2 — Build Source code is compiled. Dependencies are resolved. If this fails, nothing else runs. STEP 3 — Unit tests Every test in your codebase runs automatically. One failure stops the pipeline cold. No exceptions. STEP 4 — Static code analysis (SAST) SonarQube scans for bugs, vulnerabilities, and code smells. A quality gate defines what passes. STEP 5 — Docker image build The application and all its dependencies are packaged into an immutable container image. Tagged with the commit SHA. STEP 6 — Image push to registry The image is pushed to ECR or DockerHub. This is the artifact that will be deployed everywhere. STEP 7 — Deploy to staging The new image is automatically deployed to a staging Kubernetes cluster. No manual steps. STEP 8 — Integration tests Tests run against the live staging environment. Real HTTP calls, real database, real assertions. STEP 9 — Approval gate A human reviews and approves. One click. STEP 10 — Production deploy ArgoCD detects the approved image tag in Git and deploys to production. Zero downtime rolling update. Total time: 8–15 minutes. Manual process equivalent: 2–3 hours. #DevOps #CICD #Jenkins #Kubernetes #Automation #SoftwareEngineering #CloudEngineering

𝗦𝘁𝗼𝗽 𝗦𝘁𝗮𝘀𝗵𝗶𝗻𝗴 𝗬𝗼𝘂𝗿 𝗚𝗶𝘁 𝗕𝗿𝗮𝗻𝗰𝗵𝗲𝘀 You switch branches often. You stash changes. You check out new code. You lose your place. Git Worktree solves this. It lets you open multiple branches at once. Each branch gets its own folder. All folders link to one repo. Use it to: - Review a PR without stopping your work. - Test scripts on different branches side by side. Git includes this tool. Many developers miss it. It saves you time. Do you use Git Worktree? Source: https://lnkd.in/gcRRy8jF