I just made a commit, so why does VS Code still show that asterisk (*) on my branch name? A debugging journey through Git's "deleted" file status and what to do about it.
I changed my dev server port from 5173 to 5174 across three files, but I also had other unrelated changes in those same files! π° I only wanted to commit the port changes. My mentor walked me through Git's partial staging features: git add -p, git stash, interactive staging, and patch mode. After some trial and error (and learning what NOT to do), I successfully committed only the port changes while keeping my other work-in-progress safe. This is professional Git workflow! π―
Frontend Dev: "I just finished working on my frontend branch and want to merge it into main. Someone told me to use rebase, but when I ran git rebase main, it said 'Current branch frontend is up to date.' What does that mean? Should I use merge instead?"
Git Mentor: "Ah, this is one of the most confusing topics in Git! Let me show you the difference between fast-forward merge and rebase, and when to use each one. Your 'up to date' message actually tells us something important!"
Backend Dev: "I just successfully rebased my backend branch with 18 commits onto main! But when I try to push, Git says I need to force push. Why can't I just do a regular push? What happened to my commits?"
Git Mentor: "Ah! You've encountered one of Git's most important safety mechanisms. Let me show you exactly what happened during your rebase and why you now need force push!"
Backend Dev: "I have two worktrees - one for frontend and one for backend. When I commit in the backend worktree, does it show up in the original worktree? And when I merge backend into main, what happens to the backend branch?"
Frontend Mentor: "Great question! This is where Git worktrees become really magical. Let me show you exactly what's happening in your setup."
Backend Dev: "I don't understand why we have Phase 2 in rebasing. I thought it would be as simple as running a merge command. But in rebase, I think we do merge command too? Why the extra step?"
Frontend Mentor: "Ah! This is one of the most common confusions about Git rebase. Let me show you what's really happening under the hood."
Three ways to integrate changes in Git. Each creates a different history. Here's when to use which.
Ever wished you could go back to your first commit, add that test class you forgot, and have it magically appear in all subsequent commits? With Git's interactive rebase, you can! Let's explore how Git actually stores history and how to safely rewrite it.