An unfinished feature can block an urgent bug fix when its uncommitted files occupy the only working directory. The immediate goal is to make the next change safer and easier to explain. Begin with the branch state and the people who depend on it.
Why this deserves attention
Git’s official documentation separates the working tree, index and commit history because each command acts on a different part of that model. A workflow is easier to trust when teammates can see what changed, why it changed and how to recover if an assumption was wrong. Good habits matter more than memorising every flag. Git worktrees provide another checkout linked to the same repository, so the fix can start without hiding half-finished changes in a hurried stash. A clear explanation of the intended result is usually more valuable than a long sequence of clever commands.
A practical way forward
Create a separate worktree for the fix branch, run the relevant tests there and remove it through Git after the work is complete. Read git status before acting and inspect the diff afterwards. If the change affects a shared branch, communicate the plan before rewriting or merging history.
Picture it in a real situation
A developer can keep a redesign open in one folder while checking out the production branch in a second folder to patch a broken form. A small, named change is easier for a teammate to review. Record the commit or branch involved so a later investigation can reconstruct the choice.
What to avoid
Avoid deleting the directory manually and forgetting the linked worktree record; inspect the worktree list during cleanup. Check whether the branch is shared and whether the command can discard work. A recovery step should be understood before a risky history operation begins.
Takeaway
Make the next change small, reviewable and recoverable. Explain the intent beside the result.
Sources and further reading: Official Git documentation; Git worktree manual.