Git Stash: Temporarily Store Uncommitted Changes

⚠️ I thought I just deleted hours of work. Turns out… Git saved me. I had just committed some code, but commit message wasn’t right. Usually, my flow is: git stash git reset --soft HEAD~1 git stash apply Recommit with a better message But this time, I skipped the stash step and ran git reset --hard HEAD~1 And immediately realised — the commit wasn’t pushed, and I hadn’t stashed anything. 😅 That’s when the panic started. Then I remembered: Git almost never truly deletes things immediately. I ran: git reflog And there it was — the “lost” commit. I restored it with: git reset --hard <commit-hash> Crisis avoided. 📚 But the bigger lesson wasn’t recovery, it was understanding Git more deeply. After restoring the commit, I also learned how to properly edit history: git commit --amend → modify the last commit message No stashing. No resetting. No unnecessary risk. 🛠️  Sometimes growth as a developer isn’t about writing more code. It’s about understanding the tools better #developers #git #versioncontrol #webdevelopment #shopifydeveloper #learninginpublic

Imagine you’re working on some code and suddenly need to switch branches. Your work is not finished yet, so you don’t want to commit it. That’s where git stash helps. git stash temporarily saves your uncommitted changes and gives you a clean workspace. Think of it like keeping your work in a drawer and closing it for later. Basic Commands # Save your current work git stash # See all saved work git stash list # Want to commit all the saved changes git stash apply # Saves untracked files git stash -u # Saves ignore files,folder etc git status -a When should beginners use git stash? • When you need to switch branches quickly • When your work is half done • When you want to keep commit history clean • When you don’t want to lose changes git stash is safe, simple, and very useful once you start using Git daily #Git #BeginnerFriendly #VersionControl #LearningInPublic

Quick Git pro tip that saves hours during code reviews and keeps history readable: Use git rebase -i HEAD~n (interactive rebase) to squash, reorder, edit, or fixup commits before pushing. Example workflow: 1. git rebase -i HEAD~5 → opens editor with last 5 commits 2. Change “pick” to: • squash/s = combine into previous • fixup/f = combine but discard message • edit/e = pause to amend • reword/r = change commit message 3. Save & exit → Git applies changes step-by-step Pro moves: • Add exec lines to run tests mid-rebase • Use drop to remove bad commits entirely Clean history = happier teammates + easier bisects. Which rebase command do you use most often — squash, fixup, or something else? Share your favorite below 👇 #Git #DeveloperTips #CleanCode

Yesterday I learned something small in Git, but it actually made things clearer for me. I was working on my local branch and wanted to switch to a branch my teammate pushed. So I typed: git checkout friend-branch Git replied with: "pathspec did not match any file(s) known to git" For a second I thought I messed something up. After checking, I realized the branch was not local. It only existed on origin. That is when I discovered something I had never paid attention to before. The difference between git checkout and git switch. When I ran: git switch friend-branch Git automatically created a local tracking branch from origin and switched to it. It is a small thing. But moments like this remind me that being a developer is not just about learning new frameworks. It is about understanding your tools better every day. Every small mistake teaches something. Still learning. Always will. #Git #SoftwareDevelopment #LearningInPublic

I used to type git push origin main because the tutorial told me to. (I didn't actually know what "origin" meant.) For a long time, I treated Git like a black box. I just memorized the magic words: add -> commit -> push. I didn't understand the system, I just hoped it worked. That is dangerous. If you don't understand the tool, you live in fear of breaking the codebase. I finally clicked when I stopped memorizing commands and learned the definitions: Git is a Time Machine: It allows you to save "snapshots," not just overwrite files. Origin is a Nickname: It’s just an alias for the URL. Like saying "The Office" instead of the full address. I built this deck to explain the concepts behind the commands. Slide 14 is the "Origin" analogy that finally made sense to me. Be honest: Do you know what HEAD actually refers to? #SoftwareEngineering #Git #DevOps

For years I was told working directly off main was sacrilege. Turns out, it's the best way to use git.  I've spent years evolving how I use git, from trunk-based branching to stacked PRs with tools like Graphite, eventually landing on git diff stacking. The workflow completely changed how I think about code review and parallel work.  I also built a CLI tool called Glu to address some gaps I had with existing tooling, specifically around branch naming control and keeping track of commits across rebases. I wrote about the full journey, what diff stacking actually is, and why GitHub's recent announcement around native stacked diff support is a bigger deal than people realise. https://lnkd.in/gQQv6zc6

Confession time. I’ve built companies, exited companies, and invested in a hundred more. But I have a secret shame. I absolutely hate Git. If I have to do anything more advanced than a basic commit and push, my heart rate spikes. Suddenly you’re staring at a detached HEAD state, frantically Googling git rebase --interactive --autosquash or git submodule update --init --recursive. And my personal favorite git reflog, which is just code for "I have made a terrible mistake." The biggest unlock for me recently with tools like Claude Code is that I can finally stop pretending I enjoy managing branch complexities. I just tell the agent "Hey, take these three features, put them on a new branch, squash the garbage commits, and tag it for release v2.0." And it just does it. It handles the complex stuff like feature tags, cherry-picking, and rebasing while I focus on the actual product. We’re just finally getting back to building stuff instead of fighting with our tools. Who else is secretly relieved to never type git stash pop ever again?

Let’s be real—whether you’re spinning up a new UI component or debugging a tricky backend API, Git is the real MVP keeping everything from falling apart behind the scenes. 🛠️ I came across this fantastic visual guide to modern Git workflows and had to share it. We all know the standard push and pull, but mastering some of the slightly more advanced commands makes a massive difference in day-to-day development. A few lifesavers I always keep in mind: git reflog: The ultimate panic button when you think you’ve accidentally deleted your hard work. 😅 git stash: Perfect for when you need to switch branches mid-feature without losing your context. git squash: The best way to keep your main branch history clean before merging a messy feature branch. Having a solid grasp of version control makes collaborating so much smoother. What is the one Git command you still have to Google every time? Let me know in the comments! 👇 #Git #WebDevelopment #SoftwareEngineering #FullStack #CodingBestPractices #DeveloperTools

💻 Git commands I’ve used 99% of the time in 3+ years... You don’t need to memorize 200 Git commands. You just need to master the ones that actually power your daily workflow. Here’s my real-world Git toolkit: 🔹 𝗗𝗮𝗶𝗹𝘆 𝗕𝗮𝘀𝗶𝗰𝘀 👉 git status – Check current changes 👉 git diff – See what changed 👉 git add <file> – Stage changes 👉 git commit -a -m "message" – Commit updates 👉 git log --stat – Review commit history 🔹 𝗕𝗿𝗮𝗻𝗰𝗵𝗶𝗻𝗴 & 𝗖𝗼𝗹𝗹𝗮𝗯𝗼𝗿𝗮𝘁𝗶𝗼𝗻 👉 git checkout -b <branch> – Create new branch 👉 git checkout <branch> – Switch branch 👉 git branch – List branches 👉 git merge – Merge branches 👉 git push origin <branch> – Push changes 👉 git pull – Sync latest changes 🔹 𝗙𝗶𝘅𝗶𝗻𝗴 𝗠𝗶𝘀𝘁𝗮𝗸𝗲𝘀 (𝗛𝗮𝗽𝗽𝗲𝗻𝘀 𝘁𝗼 𝗘𝘃𝗲𝗿𝘆𝗼𝗻𝗲 😅) 👉 git commit --amend – Edit last commit 👉 git reset HEAD~1 – Undo last commit (keep changes) 👉 git reset --hard – Reset completely (careful ⚠️) 👉 git revert – Safely undo via new commit 👉 git rebase -i – Clean up commit history 🔹 𝗔𝗱𝘃𝗮𝗻𝗰𝗲𝗱 𝗯𝘂𝘁 𝗨𝘀𝗲𝗳𝘂𝗹 👉 git stash / git stash pop – Temporarily save changes 👉 git cherry-pick <commit> – Apply specific commit 👉 git show <commit> – Inspect commit details 👉 git branch -D <branch> – Delete branch 👉 git format-patch / git apply – Share patches 👉 git clone – Copy a repository That’s it. In reality, strong Git fundamentals > knowing every obscure command. Master these, and you’re already ahead of most developers. Image credit goes to respective owner... hashtag #Git hashtag #SoftwareEngineering hashtag #DeveloperTips hashtag #Programming hashtag #TechCareers hashtag #VersionControl hashtag #Coding

Yes, there is a fire, my eyes are burning ! In case of fire, better off not breaking the company codebase with those commands. Let me break this down : - ctrl-S is saving code that is not (yet) working and even less tested. - Git commit without -a will not commit added or deleted files to git. So the already broken code saved in step 1 would be even more broken. - forced git push to origin master will likely overwrite working code from previous version with your broken code. But what if there is 10 developers before the fire ? They will all overwrite and only the last dev pushing will add its broken code. - the nightmare-ish merging that will need to happen after this is likely a cause for another fire. If this is your company dev workflow, I suggest you leave the building before the fire.