Stash, Worktrees, Temporary Work, and Parallel Development Contexts: Configuration, Design Choices, and Tradeoffs

1. Context management needs conventions because both tools create hidden state

A stash hides work from normal branch history; a linked worktree hides a checkout in another directory. Neither is unsafe by definition, but unmanaged copies make it easy to forget where important work lives. A useful policy makes temporary state discoverable, short-lived, named, and convertible to durable history when its lifetime grows.

2. Give every nontrivial stash an operational message

git stash push -u -m "INC-142 | feature/metrics | interrupt for hotfix | includes notes"
git stash list
git stash show --stat stash@{0}

A message should answer why the work was parked and what context it belongs to. Avoid messages like wip when several stashes can coexist. The message is not a replacement for issue tracking, but it reduces ambiguity when you inspect the stack later.

3. Stash retention discipline: hours/days, not an archive strategy

Stashes are local ref/reflog state. Dropping or clearing entries can make their commits unreachable and eventually prunable. If temporary work survives a context switch, a reboot, a handoff boundary, or more than the team's short-lived stash window, promote it to a named branch and commit it intentionally.

4. Use predictable sibling directories for worktrees

A common layout keeps linked worktrees adjacent to the main repository:

service/
service-wt-feature-metrics/
service-wt-review-842/
service-wt-hotfix-timeout/

Predictable names make shell prompts, IDE windows, cleanup scripts, and incident runbooks easier to audit. Keep names portable across Windows, Linux, and macOS: avoid shell metacharacters, reserved platform-specific names, and ambiguous spaces when automation will consume paths.

5. Worktree-specific config is an opt-in repository-format extension

By default, repository config is shared across worktrees. Current Git supports extensions.worktreeConfig, after which git config --worktree writes configuration specific to one worktree.

git config extensions.worktreeConfig true
git config --worktree devops.context main
git config --show-origin --show-scope --get devops.context

git worktree add -b hotfix/example ../service-wt-hotfix trunk
git -C ../service-wt-hotfix config --worktree devops.context hotfix
git -C ../service-wt-hotfix config --show-origin --get devops.context

devops.context is a harmless custom key used for teaching. Real Git settings such as sparse-checkout state may legitimately differ per worktree, but do not scatter arbitrary behavioral configuration across worktrees without documenting it.

6. Know what remains shared

Enabling worktree-specific config does not turn a linked worktree into an independent clone. The object database and shared repository configuration/refs still belong to the common repository. A command in one worktree can create commits or update branch refs visible from another.

git rev-parse --git-dir
git rev-parse --git-common-dir
git config --list --show-origin --show-scope

7. Decision rule: stash only when hidden local state is truly temporary

1. If the work is coherent enough to explain and must survive or be shared, commit it on a branch.
2. If the work is incomplete but interruption is short and strictly local, stash it with a message.
3. If current work should remain physically untouched while another branch is needed immediately, add a worktree.
4. If independent dependencies, credentials, build caches, or isolation boundaries are required, use a fresh clone/workspace.

8. Worktrees versus clean clones in CI

Do not choose worktrees for CI merely because they are faster. If jobs run untrusted code, need independent credentials, or mutate repository config/refs unpredictably, clean isolation is often worth the extra cost.

9. Lock only worktrees that are intentionally unavailable, and record why

git worktree lock --reason "portable SSD disconnected during travel" /path/to/worktree
git worktree list --porcelain
git worktree unlock /path/to/worktree

A lock prevents pruning and ordinary move/remove operations. It is not a file lock that prevents developers from editing files inside a mounted worktree.

10. Prune metadata only after verifying the directory is genuinely gone

git worktree list --porcelain
git worktree prune --dry-run
git worktree prune -v

The dry-run is the same safety principle used throughout this course: inspect what Git believes is stale before changing administrative state. If the directory was moved rather than deleted, use git worktree repair instead of pruning the relationship.

11. Security boundary: worktrees share more than their filenames suggest

Linked worktrees share the common repository, including objects that may contain historical sensitive data. They are not a security boundary between trusted and untrusted jobs. Likewise, repository-local config is shared by default. Secrets should come from an external secret manager/environment with least privilege, not from committed files or casual per-repository config.

12. Worked scenario — a small DevOps team

13. Knowledge check

14. Summary

Manage temporary contexts with naming and lifetime rules. Use worktree-specific config only when version compatibility and a real per-worktree need justify it. Prefer commits for durable work, linked worktrees for parallel local checkout contexts, and clean clones for stronger CI isolation.

Authoritative references

• git-worktree
• git-config
• git-stash