Deleting a Git Branch: What Actually Happens

A few days ago, I accidentally deleted an important Git branch. - It wasn’t "merged". No one had a local copy. For a moment, I genuinely thought the work was gone. Then I remembered — Git doesn’t immediately delete the actual commits. A branch is just a pointer. I ran git reflog, found the commit hash where the branch last existed, and simply checked out that commit to recreate the branch. And just like that — it was back. One important catch: this has to be done quickly. Git’s garbage collection (GC) eventually cleans up orphaned commits. If that happens, recovery becomes almost impossible. Sometimes, the best way to understand a tool… is to almost lose your work because of it

We use Git every day, but rarely think about what’s happening internally. I took some time to explore what actually goes on when we run git add and git commit, and tried to simplify it as much as possible. Put it all together in a blog on Medium. https://lnkd.in/dpqM9kqz

5 Git commands I wish someone had shown me on day one. Everyone teaches git add, commit, push. Nobody teaches the commands that actually save you when things go wrong. 1. git stash Shelve your uncommitted work without losing it. Switch branches cleanly, come back, and run git stash pop. Done. 2. git log --oneline --graph A visual map of your entire branch history in the terminal. Essential when you're debugging "how did the codebase get into this state." 3. git bisect Binary search through your commit history to find the exact commit that introduced a bug. Sounds complex — takes 5 minutes to learn and saves hours. 4. git commit --amend Fix your last commit message or add a forgotten file before pushing. No more embarrassing "oops" commits cluttering the history. 5. git reflog Your ultimate safety net. Every HEAD movement recorded. Accidentally deleted a branch? Reset too hard? Reflog can bring it back. Almost nothing in Git is truly gone. Bonus: git cherry-pick [hash] — Apply one specific commit from another branch without merging everything else. Surgical and underused. Bookmark this for the next time something breaks at 11 PM. Which of these took you the longest to discover? #Git #CodingTips #DevProductivity #SoftwareEngineering #DevLife

Git is easy… until you mess something up. Everyone knows: 👉 git add 👉 git commit 👉 git push But one wrong command… and suddenly you’re googling like your life depends on it 💀 Here’s a Git survival cheat sheet every dev needs 👇 1️⃣ Undo last commit (but keep code) 👉 git reset --soft HEAD~1 2️⃣ Discard local changes ❌ 👉 git checkout . (or better: git restore .) 3️⃣ See what actually changed 👀 👉 git diff 4️⃣ Fix a wrong commit message ✍️ 👉 git commit --amend 5️⃣ Unstage a file 🚫 👉 git restore --staged <file> 6️⃣ Check history like a pro 🧠 👉 git log --oneline --graph --all 7️⃣ Emergency button (WIP save) 💾 👉 git stash → saves your mess temporarily Most devs don’t fear coding… They fear breaking Git history 😭 But once you understand it, Git becomes your safety net, not your enemy. Be honest What’s the worst Git mistake you’ve ever made? 👇

Git Cheat Sheet – Save This! No more Git confusion 📌 Commit git commit -m "message" 📌 History git log (branch) git log README.md (file) 📌 Push git push origin master 📌 Restore old version of a file git checkout <hash> <file> 📌 Pull (merge remote changes) git pull origin master 📌 Fetch (without merge) git fetch origin master 💡 Push rejected? git pull → resolve → git push #GitTips #CodingLife #DevEssentials

🚀 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

stash commands that I did not encounter until I use git in my projects, and it could be life saving when needed, so here is some info about it:- git stash // saves changes and reverts to the last commit. git stash pop // applies the most recent stash and removes it from the stack. git stash apply // applies the stash but keeps it on the stack. git stash list // shows all saved stashes. git stash drop // deletes a stash. git stash drop@{n} // removes specific stash.

Staging in Git acts as a middle ground or temporary holding space between your working directory (where you actually make and edit files) and your local repository (where changes are permanently saved). It represents the second phase in Git's workflow. To help understand this, the sources offer a great analogy: think of making a final commit as leaving for a party and the staging area as standing in front of the mirror before you go. While you are in front of the mirror, you haven't left yet, so you can still change your shoes or shirt if something doesn't look right. Similarly, the staging area gives you an intermediate step to review, adjust, or remove your changes before you lock them in permanently. Moving files to this stage is essentially telling Git, "All right, my changes are ready, they can move to the next step" It is a diagram of a workflow including Git & GitHub. Image from: https://lnkd.in/g4niFEZm

A mistake I used to make: jumping straight into the code. Over time I realized the real work starts before that; understanding the system, the history, and where to even look. This is a great breakdown of simple Git commands that help you do exactly that. High leverage, low effort. (link in comments)