--- schemaVersion: "1.0.0" id: "a-terminal-for-parallel-work" slug: "a-terminal-for-parallel-work" title: "A quieter terminal for parallel work" description: "Give each change a workspace, a clear owner, and a reviewable finish line." category: "Guides" tags: ["Git","Developer tools","Workflow"] date: "2026-09-29" updated: "2026-09-29" author: "PlainNerd editorial" readTime: 3 illustrationKind: "terminal" status: "published" evidenceStatus: "reference-guide" locale: "en" originalLocale: "en" --- # A quieter terminal for parallel work Reference guide\. This article draws on primary documentation and editorial recommendations; no production measurements are reported\. ## One directory, one change Parallel work becomes hard to review when several tasks change the same checkout\. Git worktrees let a repository have multiple working trees\. Each can hold a separate task without requiring a separate clone of the full repository\. ## Name the work Choose a branch and directory name that describes the intended change\. Before creating a worktree, inspect the existing branches and working trees\. The following is an example for a new branch; replace the names for your repository\. ```sh git worktree list git worktree add -b feature/search ../project-search ``` ## Make shared resources explicit A separate working tree does not isolate databases, ports, credentials, or external services\. Give each development server its own port and use disposable test data where possible\. Write down which resources are shared so the next person can predict the effects of a command\. ## Close the loop Review the diff, run the checks appropriate to the change, and commit the intended files\. Remove a finished worktree only after checking that its work is preserved\. Use Git’s worktree commands to manage its bookkeeping rather than deleting directories blindly\. [Git: worktree documentation]()