There are a bunch of posts on the internet about using git worktree command. As far as I can tell,
most of them are primarily about using worktrees as a replacement of, or a supplement to git
branches. Instead of switching branches, you just change directories. This is also how I originally
had used worktrees, but that didn't stick, and I abandoned them. But recently worktrees grew
on me, though my new use-case is unlike branching.
I have started using work trees recently as well, but have a different flow to the author and everyone else. I typically use two work trees, one on main that I do all my work on. That is work and create commits directly on the main branch.
But then to push I have another clean work tree that I use to create and switch branches on then use that to create working sets of changes by cherry-picking from master into different branches to push and create PRS from. And never edit files on this work tree so that I never have to stash anything.
Then just git pull --rebase=interactive origin/master to remove merged commits from master as they get merged upstream. This let’s me build on pending PRs or switch to other tasks at will and just sort them into separate PRs as required.
I like this as when working on a feature I often find a refactoring I need to do, so can isolate that refactoring and create a PR with only that change while continuing to work on the feature on top of the PR.
Or have some temp debugging stuff locally that I want to use across changes that will end up in different PRs without having to copy paste them between branches.
I have started using work trees recently as well, but have a different flow to the author and everyone else. I typically use two work trees, one on main that I do all my work on. That is work and create commits directly on the main branch.
But then to push I have another clean work tree that I use to create and switch branches on then use that to create working sets of changes by cherry-picking from master into different branches to push and create PRS from. And never edit files on this work tree so that I never have to stash anything.
Then just
git pull --rebase=interactive origin/master
to remove merged commits from master as they get merged upstream. This let’s me build on pending PRs or switch to other tasks at will and just sort them into separate PRs as required.I like this as when working on a feature I often find a refactoring I need to do, so can isolate that refactoring and create a PR with only that change while continuing to work on the feature on top of the PR.
Or have some temp debugging stuff locally that I want to use across changes that will end up in different PRs without having to copy paste them between branches.