|
|
|
|
|
|
by ithkuil
2 days ago
|
|
|
You're right about everything you said, but there is a flip side: with work trees you can: 1. find/list all related "clones" of the repo 2. Ensure that the same branch is not being worked on in different checkouts (which is useful if you do rebases as part of your workflow) Worktrees force you distinguish the "main" repo from the swarm of checkouts, and if you locate or name directories with a rule you can always tell which are which. For my own use, I built a little helper to create, list and destroy worktrees that fit in my workflow with Claude code: https://github.com/mkmik/ccwt |
|
|
worktrees ensure that the same local tracking branch is not being the basis for different trees. So when you do want to work on some independent things in parallel which share the same upstream branch, you have go through the annoyance of giving the local branches different names: master-2, master-alt, master-bug2359 ...
With multiple git repos instead of work trees, you just use the same name. All three of your repos can be on rev-3-branch: the same local name for the remote origin/rev-3-branch.
The most common example of this is multiple repos of the same upstream that are all on the default branch like master.
You can easily apply rebase workflow independently on all of them, and it's easily possible to add them to each other as remotes, to move commits sideways. If we commit something in repo A on master, and do a "git fetch A" in repo B, we can then easily "git cherry pick A/master" to get that commit into B's master.