一个支持工作树的设置脚本可以诊断缺失的工具，分享一个 Docker 堆栈，并隔离端口、数据库和状态，以安全并行开发。Ally Piechowski · 2026年7月28日 · 5分钟阅读 开发 git 工程管理 在我参与的一个生产应用中，一个新的 Git 工作树可以通过一个设置脚本运行：bin/setup。Setup 准备环境并退出，然后正常的开发命令运行。在这里我将使用 bin/dev 作为该存储库已经使用的命令的简写。Setup 并没有将服务器隐藏在一个巧妙的进程管理器中。bin/setup 是一个存储库拥有的可执行文件，它将检出转换成一个有效的开发环境。根据项目需要，可以称其为 make setup 或 script/bootstrap。接口比名称更重要：一个命令可以返回一个准备好的存储库或确切的修复说明。同一个命令应该可以在每一个 Git 工作树中工作。并行编码代理使得这一点变得重要，足以将其视为普通的开发基础设施。第二个检出不是第二个环境 Git 工作树是另一个检出，具有自己的工作树、HEAD 和索引，同时共享存储库的公共 Git 数据。这种分离对代码是很好的。Git 并不知道两个应用的副本都想要相同的端口、数据库、缓存键、回调 URL、Terraform 状态或容器名称。这在两个工作树需要运行时有效：git worktree add ../app-payment-fix -b payment-fix cd ../app-payment-fix bin/setup bin/dev。为一个永久克隆编写的设置脚本可以复制相同的 .env，并将每个检出指向相同的数据库。当两个工作树启动时，它们的开发服务器可能会争夺主机端口。当它们重新使用项目名称或固定的容器、网络或卷名称时，组合项目也可能重叠，并且发布的端口仍然会冲突。第二个工作树要么无法启动，要么默默地共享状态。工作树在编码代理之前就已经存在了。改变的是频率。保持两个分支开放曾经是一种偶尔的便利。现在几个代理可以同时实现和测试不相关的更改。它们的文件由 Git 隔离；它们的运行时状态必须由存储库隔离。为每个工作树运行一个完整的 Docker 堆栈是最简单的思维模型，通常也是错误的默认设置。数据库、对象存储模拟器、邮件捕获工具和其他本地服务与应用进程相比可能是昂贵的。我运行一个共享堆栈，然后为每个工作树提供自己的端口、数据库和资源名称。每台机器共享一次 每个工作树隔离 数据库和缓存服务器 开发和测试数据库名称、缓存命名空间 本地服务容器 队列名称、桶、回调 URL、基础设施资源名称 包含下载和工具缓存 应用端口、环境文件、日志、PIDs、本地状态 设置脚本派生一个可读的工作树标识，检查它与一个小的本地注册表，然后写入生成的配置，例如：WORKTREE_ID=<derived-worktree-id> APP_PORT=<allocated-port> DATABASE_NAME=app_dev_<worktree-id> TEST_DATABASE_NAME=app_test_<worktree-id> 注册分配需要一个锁，因为代理可能会同时启动设置。该锁只序列化尊重它的设置过程。一个强大的分配器应该删除过时的预留，选择一个候选端口，检查是否有当前监听器，然后原子性地提交身份。该监听器检查只是快照。开发命令仍然必须清晰报告后来的绑定冲突。一个脚本可以安全地重新运行，但在并发情况下仍然失败；仅凭幂等性是不够的。bin/setup 拥有设置 拥有 git worktree add 与正常开发命令之间的每一个步骤：引导存储库声明的工具链（我使用 mise）。运行 bin/doctor 以诊断剩余的主机要求，如有必要，以确切的修复步骤停止。确保共享的 Docker 服务正在运行且健康。分配或恢复工作树的身份和端口。生成本地环境和服务配置。创建和迁移隔离的开发和测试数据库。验证应用能否访问其依赖，然后退出。这个引导不必是 mise。我使用 mise 来固定存储库中的语言运行时、包管理器和小型 CLI 工具。设置可以对缺失的配置版本运行 mise install。Git、Docker、操作系统库和凭证可能仍然是必需的。如果一个存储库使用 mise，安装一个工具不会为每个 shell 激活它。设置应通过 mise exec -- ... 运行存储库命令，或明确要求 shell 激活，以便偶发的 shell 配置不能改变结果。这缩短了第一次提交的时间，但入门仅是第一个收益。每当一个人或代理打开一个工作树时，同样的路径都会运行。让设置尽早失败 bin/doctor 应该靠近设置的开始，并且也应该独立运行。在我添加它之前，设置可能会在发现 ffmpeg 缺失之前到达种子步骤。Doctor 现在在昂贵的 wo 之前捕获了这个问题。