What to use instead of git commit and git stash when changing branches?

I'd like to share my inconveniences and see your solutions or opinions.

I'm using git, VSCode and BitBucket.

Let's say I'm working on a big codebase and on a branch FEAT-some-new-feature. A lot of files need changes for this feature so the git changes tracking helps out a ton when navigating the codebase.

I need to do some work on this other branch FIX-some-fix. Git won't let me change branches unless I commit my work. If I commit my work, the tracking will be lost, which is a big inconvenience.

I can use git stash and git stash pop, but once I stash the changes, there is no direct indication that the branch has stashed changes. If I go back to FEAT-some-new-feature after two weeks, I might forget that I had changes stashed there. That can cause panic and if I'm being particularly stupid, I might start rewritting the whole feature from scratch.

What solution do you propose? How can I change branches without losing my change tracking or forgetting I have changes stashed? Maybe there is a git feature I don't know where you can commit changes without losing tracked file changes?

stash remains the best solution in every case but, indeed, one tends to forget about it afterwards. So there's at least two approaches you may try:

Resetting a regular commit

If you need to switch onto something else for a couple of days or something, you may just add the complete state of your current working directory and commit it into a single commit named backup or something, then checking out your other branch.

When you want to go back to your former task and resume your work, first check out the branch (which will bring you back to your backup commit in a "clean" state), then reset the branch to the previous commit using git reset or git reset --mixed (mixed being the default option).

This will bring back the branch and the index to the previous commit while preserving the working directory's content, and you'll retrieve the tracking status that git status used to show.

Be aware though that it's about rewritting history. If you need to push that beyond your local machine, ensure first that the server will let you do.

Use git worktree

git worktree will enable you to open a secondary, temporary working directory aside of the regular one. It's especially useful when you need to checkout two distinct versions of a same repository, when you need compare versions of a library, for instance.

In your particular case, it's a convenient way to work on another part of a project without the need to alter you regular work place.

This way, you won't need to rewrite history, but one tends to forget about those additional directories too, so make sure to clean it up completely when you're done with it.

I believe that stashes are actually the solution to your problem.

> [...] after two weeks, I might forget that I had changes stashed there.

You don't have to forget about stashes. When you run your git log --oneline --all --graph command to see the whole tree, it normally doesn't include "stashed versions," with the only exception being your most recent stash.

To make all stashes visible, include --reflog in the aforementioned command every time you run it. The reflog is history of objects that would normally not appear, in most cases because they are considered garbage by Git or they are stashes.

It seems you have many uncommited changes in your working dir for a long time. That is not a recommended way to use git (or any VCS). You should make small, logical commits often. Maybe your task is really big and should be divided in smaller tasks.

On the other hand, maybe a sollution with remote feature branch could help if you are note using it. Commit your changes to the branch you are working on and push it to origin. Create a draft pull request (not sure if Bit bucket supports PR drafts already), then you can still review your overall changes, before merging them into main branch.

Why you should commit often? Conflicts are easier to handle and the possibility of loosing the work is smaller (when you push often its even smaller)