Should we delete worktrees after every CI job?

For ephemeral PR jobs, remove the worktree and prune when disk free space falls below about fifteen to twenty percent or when stale worktrees age past roughly seven days. Keep long-lived release worktrees only on dedicated hosts with explicit ownership tags.

Who resolves lockfile conflicts on a shared Mac?

The branch author updates Podfile.lock or package-lock.json in Git; the shared Mac only runs install steps in isolated worktrees. Block merges that change lockfiles without review when multiple apps share one CocoaPods cache path.

How do we roll back a bad parallel build?

Stop the job, remove its worktree path, run git worktree prune, clear that job DerivedData subfolder, and re-queue once the branch lockfile matches origin. Never reset the main bare or primary clone from a worktree job.

2026 Shared Remote Mac: Git Worktree Parallel Builds & Lockfile Conflict Decision Matrix

Small teams that share one remote Mac hit the same wall: everyone wants parallel builds, but one wrong lockfile step can stall the whole pool. This guide names the audience, lists core search terms, compares Git worktree layouts to multi-clone setups, gives CocoaPods and npm policies, caps concurrency, and ends with rollback plus a compact decision matrix you can paste into a runbook.

Audience and core keywords

Who this is for: squads of roughly three to twelve engineers who rent or share a remote Mac pool for iOS, macOS, or cross-platform CI, often mixing SSH sessions and automated jobs. You care about fair collaboration, predictable resource pool behaviour, and stability when two pipelines touch the same disk.

Core keywords: remote Mac, Git worktree, parallel builds, lock file, conflict, shared host, DerivedData, CocoaPods, npm, queue depth, rollback.

Pain points on shared build hosts

Hidden coupling. Two jobs write the same Pods folder or global npm cache and race during resolve steps.
Branch skew. One developer rebases while CI runs; the host keeps stale Podfile.lock or package-lock.json in a dirty tree.
Disk and Simulator pressure. Parallel Xcode builds saturate SSD and booted simulators unless you cap jobs and isolate caches.

Git worktree vs single-repo multi-workspace

Use one primary clone plus Git worktree paths when you want many branches on one shared machine without duplicating the entire object database. Compare that to multiple separate clone folders.

Dimension	Git worktrees	Multiple full clones
Disk for Git objects	Shared `.git`; lower duplication.	Each clone carries its own object store; simpler mental model.
Parallel safety	Strong when each worktree has its own build dir and dependency prefix.	Strong when paths never overlap; weaker if scripts assume a fixed root.
Ops complexity	Requires `git worktree add/remove/prune` hygiene.	Easier for juniors; more cleanup of abandoned folders.
Best default	Busy shared remote Mac with many short PR builds.	Long-lived product lanes with totally different remotes or credentials.

CocoaPods, npm and lockfile strategy

Treat lockfile files as source truth. The shared host should never “fix” them silently.

CocoaPods: run pod install with a per-worktree --project-directory or explicit sandbox; commit Podfile.lock in Git; block CI if the lock drifts from the branch tip.
npm / pnpm / Yarn: prefer npm ci or the package-manager equivalent inside each worktree; pin Node via .nvmrc or Volta.
Caches: isolate npm cache or CocoaPods cache per pool tier when teams mix unrelated apps; otherwise use one cache but serialize install steps.

Pair this with the shared remote Mac pool FAQ for queue and quota patterns that reduce conflict bursts.

Concurrency caps and queues

Parallel builds need ceilings. Start with one heavy Xcode archive per Mac class, allow two light static checks only when sustained CPU stays under about seventy-five percent and free RAM stays above roughly eight gigabytes. Keep global pending depth near twenty jobs per pool; alert instead of silently queueing for hours. Align labels and runner routing with the self-hosted runner routing matrix so Git semantics match real hardware.

Decision matrix and parameters

Signal	If true, choose	Parameter
Many short branches per day	Worktrees plus automated prune	Max open worktrees about eight per host until you add nodes
Frequent Pod or npm races	Per-worktree install dirs or serialized install mutex	One install flight per pool lane at a time
Release archives compete with PR noise	Split hosts or time windows	Dedicated release label with zero PR workflows
Disk pressure	Purge DerivedData and stale trees	Trigger cleanup below fifteen to twenty percent free space

Rollback and cleanup FAQ

How do we roll back a poisoned worktree?: Stop the job, remove the worktree path, run git worktree prune, delete that job’s DerivedData subfolder, and re-run from a clean fetch. Never run git reset --hard on the primary shared clone from inside an uncontrolled script.
When should we wipe caches?: After failed resolves, signing errors tied to stale pods, or when caches exceed roughly thirty to eighty gigabytes per tier. Always keep keychain and provisioning assets out of blind bulk deletes.
Who owns cleanup on a pooled Mac?: Name a weekly owner; log free space, open worktrees, and queue depth. Tie alerts to the same thresholds you use for stability reviews.

Executable rollout steps

Create one bare or primary repo on the remote Mac; document the canonical path.
Add a naming convention for worktrees, for example /builds/<repo>/wt-<branch-slug>.
Wire CI to create or refresh a worktree per job, then run installs with per-tree prefixes.
Enforce lockfile-only installs in CI; fail fast on dirty trees.
Set concurrency caps, queue depth alerts, and weekly prune cron or LaunchAgent tasks.

Citable parameters

Heavy compile concurrency: start at one active job per Mac class.
Light checks: up to two when CPU and RAM headroom stay in the safe band above.
Queue depth alert near twenty pending jobs per pool.
Disk cleanup when free space falls below roughly fifteen to twenty percent.

Need access patterns before you scale worktrees? Read the SSH vs VNC selection guide, then return here for layout rules.

Add nodes when worktrees outgrow one Mac

Meshmac remote Mac plans let you split PR and release pools, pin Xcode per machine, and keep parallel builds predictable. Open the homepage to compare hardware tiers and pricing without logging in, browse help for SSH and VNC setup, and explore the blog for multi-node guides when your resource pool needs another host.

Rent a Mac (browse without login) Help center More articles