Testing Microservice Changes from Git Worktrees End to End Without the Terminal Tab Explosion

Source: Dev.to

TL;DR

I built a visual CLI‑tool called Recomposable to solve the pain of testing Claude‑generated code that lives in Git worktrees.

The Problem

When using Claude Code with Git worktrees you often have several branches of the same repository checked out at the same time:

• Claude works in one worktree.
• You review / run the rest of the stack in another.

This works fine for a single‑service project, but it quickly breaks down for a micro‑services architecture.

You need to verify that the changes Claude made to one service still work with the rest of the stack. That means:

1. Rebuilding only that service from the worktree’s code.
2. Keeping every other service on the main branch.

Docker Compose has no notion of worktrees – it only sees files on disk – so you end up doing a lot of manual path‑juggling.

Manual Workflow (Current State)

Every step requires you to remember or copy the worktree path, and you must also keep track of which compose file belongs to which service.
There is no overview of which service is running from which branch.

You can hide some of the friction with shell aliases or a Makefile, but you still lack:

• A quick visual cue of which service runs from which worktree.
• Automatic updates when new worktrees appear.

Introducing Recomposable (v1.1.4)

Recomposable is a Docker‑Compose TUI built for development workflows.
Version 1.1.4 adds worktree switching as a first‑class feature.

How it works

1. Press t on any service in the UI.
2. A picker shows all available Git worktrees (populated via git worktree list --porcelain).
3. Use j/k to navigate, Enter to select.
4. The service is stopped, rebuilt from the selected worktree’s compose file, and started again.

That’s it – no manual paths, no extra docker compose -f … flags, no extra terminal tabs.

UI Overview

When services run from different branches a WORKTREE column appears automatically.
Non‑main branches are highlighted in yellow.

SERVICE        STATUS   BUILT   PORTS   WORKTREE
auth-service   running  2m ago  5001    fix-oauth
api-gateway    running  1h ago  8080    main
web-app        running  3d ago  3000    main

• No need to remember paths.
• No need to guess which branch a container was built from.

Under the hood

• Discovery – git worktree list --porcelain runs from the compose file’s directory to discover all worktrees.
• Mapping – The tool maps the original compose file path to the same relative path inside the target worktree. If the file or service does not exist in the target worktree, an error is shown.
• Override storage – The selected worktree override is stored per‑service, so all subsequent operations (rebuild, restart, logs, exec, watch, dependency‑aware cascade rebuild) automatically use the overridden compose file.
• Switch back – Press t again and pick the original worktree (usually main).

Typical workflow with Recomposable

1. Start Recomposable in your project root – the full stack runs on main.
2. Open Claude Code and tell it to work on auth-service in a new worktree.
3. Claude makes changes; you need to verify end‑to‑end.
4. In Recomposable, navigate to auth-service, press t, select Claude’s worktree.
5. The service rebuilds from Claude’s branch while the rest of the stack stays on main.
6. Inspect logs, send requests, verify behavior – all inside the TUI.
7. When finished, press t again and switch back to main.

No extra terminal tabs, no path juggling, no guessing.

The approach scales: if Claude works on three services across two worktrees, you can switch all three, and the WORKTREE column instantly tells you what’s running where.

Future‑Proofing the Feature (Ideas & Gaps)

Implementing any of these would make the tool even more powerful for teams that heavily rely on the Claude Code + worktree pattern.

TL;DR (again)

• Problem: Verifying Claude‑generated changes across multiple micro‑services requires tedious manual worktree path handling.
• Solution: Recomposable – a Docker‑Compose TUI that lets you switch any service to any Git worktree with a single keystroke, showing the current worktree per service in a clear table.
• Result: No more copy‑pasting paths, no extra docker compose -f … flags, and an at‑a‑glance view of which branch each container runs from.

Give it a try, and let the UI do the heavy lifting for you!

# Recomposable – Multi‑service Worktree Switch

> “0 commits ahead” is a different risk profile than a change that only touches a single config file.

## What it does

Recomposable lets you switch **all services** in a repository from one Docker Compose file to the same worktree with a single action.  
When a change spans multiple services, you no longer have to switch each service individually – the friction disappears.

## Installation

```bash
npm install -g recomposable

Quick start

1. Navigate to a directory that contains a docker‑compose.yml file.

2. Create a recomposable.json that points to the compose files you want to manage.

3. Run the tool:

   recomposable

The worktree feature works out‑of‑the‑box with any Git repository that has multiple worktrees.

Links

• GitHub:
• npm:

## What it does

Recomposable lets you switch **all services** in a repository from one Docker Compose file to the same worktree with a single action.  
When a change spans multiple services, you no longer have to switch each service individually – the friction disappears.

## Installation

```bash
npm install -g recomposable

Quick start

1. Navigate to a directory that contains a docker‑compose.yml file.

2. Create a recomposable.json that points to the compose files you want to manage.

3. Run the tool:

   recomposable

The worktree feature works out‑of‑the‑box with any Git repository that has multiple worktrees.

Links

• GitHub:
• npm: