My/Pref/Dev/Tool/git/Worktree
- My preferences related to git/worktrees
- DO
- store worktrees inside the project folder, in a gitignored
<proj-root>/.worktrees/ directory- why the dot prefix: Logseq only skips directories that start with
. on its own; a plain worktrees/ directory still gets scanned and its files treated as graph pages/assets even when it's gitignored, so the directory itself must be dot-prefixed. Also, it makes it easier to find in yazi as the . folders appear at the top. - why one shared location: keeping every tool's worktrees under the same
<proj-root>/.worktrees/ path, rather than letting each tool pick its own default (e.g. .claude/worktrees/), preserves my ability to switch between tools without hunting for scattered worktree directories
- name each worktree after its branch, replacing
/ with - and dropping the branch-type prefix- Example/Good
- note: branch names here are not binding, they should follow repo conventions. the important thing is that there is a correspondence between worktrees and branches for short-lived tasks.
- branch
codekiln/130-add-auth -> <proj-root>/.worktrees/codekiln-130-add-auth - branch
AB-1234-add-auth -> <proj-root>/.worktrees/AB-1234-add-auth - branch
docs/add-directory-grounding -> <proj-root>/.worktrees/docs-add-directory-grounding
- in Claude Desktop, whose Worktree location setting stores worktrees inside the project but isn't configurable to
.worktrees/, use its fixed <proj-root>/.claude/worktrees/ directory instead — the one accepted exception to the shared-location principle above, since the path is dictated by the tool; still gitignored
- DO NOT
- store worktrees as siblings of the project folder
- put the branch-type prefix (
feature/, fix/, docs/) in the worktree directory name
- two species, named differently
- ephemeral — created for one branch and removed once it lands; directory named after the branch, per the DO rules above
- standing — kept alive across many branches as an agent inbox; directory named after the agent (
<proj-root>/.worktrees/reviewer), since no single branch describes it