A few days ago, I posted a discussion about Git Worktree, and the comment section had a lot of specific experience sharing.

I’ve organized the core content below, with links to each source for easy reference:

1. Fixed branches and workstation reuse, source: @sjdhoome Many people find Worktree cumbersome, mainly because you have to reinstall dependencies every time you create a new one, and clean up afterward.

This friend’s approach is to avoid frequent creation and deletion, instead keeping 8 fixed-numbered branches resident locally (e.g., worker-1 to worker-8), all uniformly tracking the main branch:

When a new requirement comes in, pick an idle branch and start a session for development; After completion, submit a PR to merge into the main branch;

In that directory, run git rebase origin/main once, and the workstation is restored to the latest clean state, ready to be handed off directly to the next task. This way, dependencies (like node_modules) only need to be installed once, saving the hassle of repeatedly adding and deleting directories.

2. Soft links for configuration and automatic port allocation, source: @dlzhou2 The most common practical issue when using Worktree is that untracked files don’t sync, like .env getting lost, or local port conflicts when starting services simultaneously.

A more universal solution is to automate via scripts: When creating a new directory, the script automatically soft-links (ln -s) the main project’s .env and node_modules over, ensuring config sync without duplicating disk space; When starting the service, the script dynamically assigns different port numbers based on the directory number (e.g., 3001, 3002), avoiding local services stepping on each other.

3. Strict control of merge permissions, source: @tootoocvc and @ysj_aaron

When developing with multiple branches or multiple Agents in parallel, it’s easy to run into a “whoever commits faster doesn’t have to deal with conflicts” race condition, leaving the later submitter to bear the heavy merging cost.

The suggestion here is: Branches can be spun up freely based on tasks, but keep only one merge entry point for the main trunk.

Code completed at each workstation is first uniformly merged into a local validation branch for integration testing, ensuring overall logic is sound before formally merging into the main trunk, avoiding arbitrary cross-merges between branches.

4. Auxiliary tools and automation flows mentioned by the community

@samzong’s open-source gmc: Project URL: https://github.com/samzong/gmc Supports creating multiple workstations with a single command, and includes built-in cross-workstation sharing of .env and dependency directories;

@roylee0x’s recommended worktrunk: Project URL: https://worktrunk.dev Written in Rust, supports automatically copying configs and running dependency installs via hooks when creating new workstations;

@shukebeta’s Agent automatic task framework: Docs URL: https://mat-docs.shukelabs.com Implements automatic task claiming from GitHub, opening Worktrees, auto-merging and cleanup upon completion.

samzong/gmc

Source: https://github.com/samzong/gmc

gmc

Parallel worktrees for parallel AI agents — plus AI-generated commits.
A Git workflow CLI built for the AI coding era: spin up a worktree per agent, share .env and node_modules across them, and let an LLM write the commit when you're done.

Installation

Homebrew (macOS/Linux)

brew install samzong/tap/gmc
# or
go install github.com/samzong/gmc@latest

Features

Rust dependency cache

New Rust worktrees automatically cache dependencies with Kache. Keep using the same gmc and Cargo commands; no separate installation or configuration is required. Packages selected by Cargo retain native incremental compilation, and each worktree keeps its own target directory.

Setup discovers root and nested Cargo.toml files, including multiple Rust projects in a monorepo. Parent Rust roots cover their descendants; existing .cargo directories or compiler wrappers are preserved. Dependency/build directories, symbolic links, and nested Git repositories are excluded from discovery. It adds ignored local Cargo configuration without changing global configuration or tracked files. The first eligible creation downloads a pinned, checksum-verified Kache release. Tools and a local cache capped at 10 GiB live under ${XDG_DATA_HOME:-~/.local/share}/gmc/rust-cache. Unavailable setup leaves normal Cargo builds available; diagnostics use gmc’s existing --debug flag.

Config

Config lives at ~/.config/gmc/config.yaml (legacy ~/.gmc.yaml still works). A project-level .gmc.yaml also applies, but it is repository content and untrusted, so it may only set role, model and enable_emoji — never api_key, api_base or prompt_template. Those three decide which credential is used, where it is sent, and which local file is read into the prompt, so they come only from your own config or GMC_* variables. Names passed with --config or GMC_* always win over a project config, and gmc warns on stderr whenever it ignores something from one. Run gmc init for a guided setup, or set fields manually:

gmc config set apibase https://api.openai.com/v1
gmc config set apikey  sk-...
gmc config set model   gpt-4.1-mini
gmc config set role    "Backend Developer"

Custom prompt template: set prompt_template to a YAML file whose template key holds a prompt using the {{.Role}}, {{.Files}} and {{.Diff}} variables. A file without a template key, or an empty one, is reported and the built-in template is used instead.

template: |
  {{.Role}}, summarize the changes below as one Conventional Commits line.

  Files:
  {{.Files}}

  Diff:
  {{.Diff}}

Task workflow

gmc task uses an embedded plan -> code -> review -> ship workflow when no user workflow is configured. The default reference lives at internal/task/default_workflow.yaml.

To customize it:

mkdir -p ~/.config/gmc
cp internal/task/default_workflow.yaml ~/.config/gmc/workflow.yaml

Shell completion

gmc completion zsh  > ~/.zsh/completions/_gmc
gmc completion bash > ~/.bash_completion.d/gmc

Troubleshooting

oh-my-zsh git plugin conflicts with gmc

If you use oh-my-zsh with the git plugin enabled, it defines:

alias gmc='git merge --continue'

That alias shadows the gmc CLI, so commands like gmc or gmc version run git merge --continue instead.

Fix: add this to ~/.zshrc after source $ZSH/oh-my-zsh.sh:

unalias gmc 2>/dev/null

Then reload your shell (source ~/.zshrc) or open a new terminal.

Workaround without changing config: prefix the command to bypass the alias:

\gmc version
# or
command gmc version

If you still want a short alias for git merge --continue, pick a different name (for example gmcont) before removing gmc.

License

This project is licensed under the MIT License - see the LICENSE file for details

陈大黄 (@realchendahuang): 我很好奇一个问题：

大家在日常编码工作中会使用git WorkTree 并行开发吗？

使用git WorkTree的最佳实践是什么？