Skip to main content
Glama
yongjip

io.github.yongjip/mergetrain

by yongjip

mergetrain

CI PyPI Python License: MIT

Parallel agents need a serial integration spine.

mergetrain is a local-first deploy train for coding-agent worktrees. Agents commit and enqueue their branches; one runner assembles them in order, tests the combined tree, and atomically updates your Git refs only after explicit approval. It is intentionally optimized as an owner-operated local utility, not a hosted team platform.

The problem

Worktrees let several agents edit one repository without sharing a checkout. They do not decide landing order, test the combined result, prevent push races, or tell you what happened if a laptop dies mid-push.

Without an integration boundary, the human becomes that boundary: rebase every finished branch, rerun gates after each merge, resolve cross-branch failures, and decide which session may push. The parallel coding gain disappears at the last mile.

mergetrain makes that last mile a durable protocol:

agent branches → FIFO queue → isolated integration worktree → combined gates
               → explicit approval → one atomic push → post-push verification

Related MCP server: github-mcp

Who should use it?

Use mergetrain when:

  • multiple coding agents finish branches in the same repository throughout the day;

  • agents work in Git worktrees and should enqueue rather than push deploy refs;

  • the combined result must pass local tests before it lands;

  • you want unattended processing only for explicitly pre-approved jobs; or

  • one local hub should show queues and runners across several repositories.

It is harness-agnostic: Codex, Claude Code, scripts, and humans all use the same CLI and JSON contract.

Who should not use it?

You probably do not need mergetrain when:

  • one person or agent lands one branch at a time;

  • every change already goes through a PR and your forge-native merge queue;

  • you need a hosted review UI, organization-wide permission system, or remote runner service; or

  • you are looking for a general job queue, CI provider, or deployment platform.

For PR-first teams, use GitHub Merge Queue or GitLab Merge Trains. mergetrain is for local-agent, worktree-first integration, with or before a PR.

Enforcement boundary

Lease tokens fence concurrent and stale mergetrain runners. They do not intercept an arbitrary git push from a task agent that has shell access and an integration-branch credential. To make “one runner owns the push” an enforced property rather than a protocol assumption, use this topology:

task agents: commit + exact-SHA enqueue; no integration push credential
runner:      separate deploy identity
remote:      protected integration branch; runner or reviewed PR path only

Without credential separation and remote protection, mergetrain still provides safe train assembly and recovery semantics, but it cannot prevent a participant from bypassing the queue. See the security boundary.

See it in 60 seconds

uvx mergetrain demo

The demo creates a disposable repository and local bare remote, then runs four real branches through FIFO merge, a combined-only gate failure, conflict attribution, and deployment of the compatible train. Use --keep to inspect the result afterward.

Install and first run

# Install the machine-level CLI
uv tool install mergetrain          # or: pipx install mergetrain
# macOS: brew install yongjip/tap/mergetrain

cd /path/to/your/repo

# Write .mergetrain.yaml plus agent instructions
mergetrain init --project my-app --write

# After an agent commits its task branch
mergetrain enqueue \
  --task "add health check" \
  --branch agent/health \
  --capture-sha

# Inspect first, then validate or deploy explicitly
mergetrain status --json
mergetrain run-batch --validate-only
mergetrain run-batch --deploy

deploy names the configured atomic Git ref update; it does not imply an App Store, Kubernetes, or other provider release.

mergetrain init also writes agent-facing instructions. The essential rule is simple: agents commit and enqueue; one runner owns merge → test → push → verify. Unattended daemons process only jobs that a human explicitly enqueued with --auto.

See the quickstart for configuration, dashboard, daemon, and multi-repository Hub setup.

Why not just worktrees and git merge?

Worktrees solve parallel editing. mergetrain solves serialized integration.

Integration concern

Worktrees + manual merge

mergetrain

Landing order

A person or agent decides repeatedly

Durable FIFO queue

Combined validation

Rerun manually after each merge

Gates run over the exact assembled train

Cross-branch failure

Diagnose by hand

Isolation runs identify the conflicting pair

Push ownership

Every session can race the ref

One lease-fenced runner owns the push

Approval

Shell convention

Explicit validate/deploy intent; --auto is opt-in

Crash recovery

Infer from local logs

Reconcile SQLite evidence against remote refs

Plain worktrees remain the execution lanes. mergetrain is the spine that joins their results without turning the operator into a merge coordinator.

Why not GitHub or GitLab merge queues?

They solve a related problem for a different operating model.

Forge-native queue

mergetrain

Primary unit

Pull/merge request

Committed local task branch

Validation

Forge merge group + remote CI

Local assembled train + shell gates

Review

Built-in conversation and approvals

No code-review UI

Infrastructure

Forge integration and hosted services

Local SQLite, Git worktrees, any Git remote

Best fit

PR-first teams and distributed review

High-throughput local agent integration

The models can coexist: push a validated train to a review branch and open one PR, or reserve individual PRs for changes that need discussion. The PR workflow guide covers direct, one-PR, split-PR, and validation-only patterns.

Core safety guarantees

  • Exact train identity. Approval names the task HEADs and integration base; changed branches or a moved base cannot silently reuse that approval.

  • Combined gates before push. A green branch is not enough. The assembled train passes the configured gates, or nothing lands.

  • One fenced mergetrain owner. SQLite claims and lease tokens prevent concurrent or stale mergetrain runners from mutating the same train; remote enforcement additionally requires the credential topology above.

  • Atomic remote update. Payload refs and a permanent refs/mergetrain/deploys/<sha> recovery ref update together.

  • Remote-truth recovery. Write-ahead markers and pinned commits let reconcile/recover determine whether a killed push landed, without replaying a successful deploy or calling a missing one shipped.

  • Explicit automation. A bare run never deploys. Daemons touch only pre-approved --auto jobs, and MCP deploy still requires attributable human confirmation.

  • Observable state. doctor, status, inspection, events, and statistics expose structured state and the next safe action instead of asking an agent to infer it from processes or prose.

Queue state, locking, train assembly, and gates stay local. Your configured Git remote and post-push verification may still use external services. Gate and verify commands are trusted code; review the security boundary before enabling unattended jobs.

These guarantees are exercised on macOS and Linux across Python 3.10–3.14 and on Windows, including real-Git fault injection around git push --atomic. A dedicated soak repository completed 20 landed trains at a 100% land rate, including planned conflict recovery and a real killed-push reconciliation whose verdict matched the remote. See the soak evidence, then use mergetrain stats --json to inspect evidence from your own queue.

Go deeper

Status

The package version is v2.0.0. Machine-contract major 2 is additive-only: existing JSON keys are not removed or renamed without another contract-version change. Issues and operating reports are welcome on GitHub.

License

Released under the MIT License.

Maintenance

ActivityActive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Local MCP server for safe GitHub developer workflows. Enables pulling main, creating feature branches, pushing them, and opening ready-for-review pull requests via tools like github_create_feature_branch and github_create_pull_request.
    6
    118
    MIT
  • A
    license
    Not graded
    quality
    B
    maintenance
    Exposes a governed, provenance-grounded autonomous delivery pipeline as an MCP server, enabling AI coding assistants like Claude Code or Codex to initiate requirements-to-PR workflows with human approval gates and full audit.
    8
    MIT
  • A
    license
    C
    quality
    B
    maintenance
    A policy-aware MCP server for GitHub and GitHub Actions that enables safe AI-assisted infrastructure workflows—inspecting repositories, preparing branches and pull requests, and constrained remote mutations behind explicit preview-bound approval tokens.
    18
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/yongjip/mergetrain'

If you have feedback or need assistance with the MCP directory API, please join our Discord server