worktrunk 0.37.0

---
source: tests/integration_tests/help.rs
info:
  program: wt
  args:
    - step
    - "--help"
  env:
    CLICOLOR_FORCE: "1"
    COLUMNS: "500"
    GIT_EDITOR: ""
    LANG: C
    LC_ALL: C
    NO_COLOR: ""
    PSModulePath: ""
    RUST_LOG: warn
    SHELL: ""
    TERM: alacritty
    WORKTRUNK_APPROVALS_PATH: /nonexistent/test/approvals.toml
    WORKTRUNK_CONFIG_PATH: /nonexistent/test/config.toml
    WORKTRUNK_SYSTEM_CONFIG_PATH: /etc/xdg/worktrunk/config.toml
    WORKTRUNK_TEST_CLAUDE_INSTALLED: "0"
    WORKTRUNK_TEST_DELAYED_STREAM_MS: "-1"
    WORKTRUNK_TEST_EPOCH: "1735776000"
    WORKTRUNK_TEST_NUSHELL_ENV: "0"
    WORKTRUNK_TEST_OPENCODE_INSTALLED: "0"
    WORKTRUNK_TEST_POWERSHELL_ENV: "0"
    WORKTRUNK_TEST_SKIP_URL_HEALTH_CHECK: "1"
---
success: true
exit_code: 0
----- stdout -----
wt step - Run individual operations

The building blocks of wt merge — commit, squash, rebase, push — plus standalone utilities.

Usage: wt step [OPTIONS] <COMMAND>

Commands:
  commit        Stage and commit with LLM-generated message
  squash        Squash commits since branching
  rebase        Rebase onto target
  push          Fast-forward target to current branch
  diff          Show all changes since branching
  copy-ignored  Copy gitignored files to another worktree
  eval          [experimental] Evaluate a template expression
  for-each      [experimental] Run command in each worktree
  promote       [experimental] Swap a branch into the main worktree
  prune         [experimental] Remove worktrees merged into the default branch
  relocate      [experimental] Move worktrees to expected paths

Options:
  -h, --help
          Print help (see a summary with '-h')

Global Options:
  -C <path>
          Working directory for this command

      --config <path>
          User config file path

  -v, --verbose...
          Verbose output (-v: info logs + hook/template output; -vv: debug logs + diagnostic report + trace.log/output.log under .git/wt/logs/)

Examples

Commit with LLM-generated message:

  wt step commit

Manual merge workflow with review between steps:

  wt step commit
  wt step squash
  wt step rebase
  wt step push

Operations

- commit — Stage and commit with LLM-generated message
- squash — Squash all branch commits into one with LLM-generated message
- rebase — Rebase onto target branch
- push — Fast-forward target to current branch
- diff — Show all changes since branching (committed, staged, unstaged, untracked)
- copy-ignored — Copy gitignored files between worktrees
- eval — [experimental] Evaluate a template expression
- for-each — [experimental] Run a command in every worktree
- promote — [experimental] Swap a branch into the main worktree
- prune — Remove worktrees and branches merged into the default branch
- relocate — [experimental] Move worktrees to expected paths
- <alias> — [experimental] Run a configured command alias

See also

- wt merge — Runs commit → squash → rebase → hooks → push → cleanup automatically
- wt hook — Run configured hooks

Aliases [experimental]

Custom command templates configured in user config (~/.config/worktrunk/config.toml) or project config (.config/wt.toml). Aliases support the same template variables as hooks.

  # .config/wt.toml
  [aliases]
  deploy = "make deploy BRANCH={{ branch }}"
  port = "echo http://localhost:{{ branch | hash_port }}"

  wt step deploy                            # run the alias
  wt step deploy --dry-run                  # show expanded command
  wt step deploy --env=staging              # pass template variable
  wt step deploy --var env=staging          # equivalent long form
  wt step deploy --my-var=value             # hyphens become underscores ({{ my_var }})
  wt step deploy --yes                      # skip approval prompt

Hyphens in variable names are canonicalized to underscores at parse time, so --my-var=value is referenced as {{ my_var }} in templates. This lets flags use natural kebab-case while avoiding the minijinja parser's interpretation of {{ my-var }} as subtraction.

Multi-line aliases work too. This up alias fetches all remotes and rebases each worktree onto its upstream, skipping worktrees without a tracking branch or with a rebase already in progress:

  # ~/.config/worktrunk/config.toml
  [aliases]
  up = '''
  git fetch --all --prune && wt step for-each -- '
    git rev-parse --verify -q @{u} >/dev/null || exit 0
    g=$(git rev-parse --git-dir)
    test -d "$g/rebase-merge" -o -d "$g/rebase-apply" && exit 0
    git rebase @{u} --no-autostash || git rebase --abort
  ''''

  wt step up

Multi-step aliases run commands in order using [[aliases.NAME]] blocks. Each block is one step; multiple keys within a block run concurrently.

  # .config/wt.toml
  [[aliases.release]]
  test = "cargo test"
  
  [[aliases.release]]
  build = "cargo build --release"
  package = "cargo package --no-verify"
  
  [[aliases.release]]
  publish = "cargo publish"

Here test runs first, then build and package run together, then publish runs last. A step failure aborts the remaining steps.

When defined in both user and project config, both run — user first, then project. Project-config aliases require command approval on first run, same as project hooks. User-config aliases are trusted.

Inside an alias body, an inner wt switch (or wt switch --create) passes its cd through to the parent shell, so an alias wrapping wt switch --create lands the shell in the new worktree just like running it directly.

Alias names that match a built-in step command (commit, squash, etc.) are shadowed by the built-in and will never run.

----- stderr -----