Menu
I read Github's post on git-worktree. They write:
Suppose you're working in a Git repository on a branch called
feature, when a user reports a high-urgency bug inmaster. First you create a linked working tree with a new branch,hotfix, checked out relative to master […] You can fix the bug, push hotfix, and create a pull request.
When I'm working on a branch called feature and some high-urgency bug in master is reported, I usually stash away whatever I'm working on and create a new branch. When I'm done, I can continue working. This is a very simple model, I've been working like that for years.
On the other hand, using git-worktree has its own limitations:
For example, it's not allowed to have the same branch checked out in two linked working trees at the same time, because that would allow changes committed in one working tree to bring the other one out of sync.
Why would I choose a more complicated workflow for a problem that's already been solved?
Is there anything about git-worktree that couldn't be done beforehand and that justifies this whole new, complex feature?
999
The Git worktree command allows you to checkout and work in multiple Git branches simultaneously.
Those 5GB should be mainly your files as checked out in their new branch: Git has to copy them all to their new folder through git worktree . Refs are shared across all working trees ( /path/main/.
prune Prune working tree information in $GIT_DIR/worktrees. remove Remove a working tree. Only clean working trees (no untracked files and no modification in tracked files) can be removed. Unclean working trees or ones with submodules can be removed with --force.
You can have many branches in your repository, but only one of these will be "checked out" as the working-tree so that you can work on it and make changes. git worktree adds the concept of additional working trees. This means you can have two (or more) branches checked-out at once.
For me, git worktree is the biggest improvement since a long time. I'm working in enterprise software development. There, it is very common that you have to maintain old versions like what you released 3 years ago. Of course you have a branch for each version so that you can easily switch to it and fix a bug. However, switching is expensive, because in the meantime you completely restructured the repository and maybe build system. If you switch, your IDE will run mad trying to adapt the project settings.
With worktree, you can avoid that constant reconfiguration. Checkout those old branches in separate folders using worktree. For each branch, you got an independent IDE project.
Of course this could have been done in the past by cloning the repo several times and this has been my approach so far. However, that also meant wasting hardrive space and worse needing to fetching the same changes from the repo several times.
98
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
