multi-gitter CLI
multi-gitter runs one script across multiple Git repositories and creates pull requests for the resulting file changes.
- 1,250 ★ on the repository
- Last commit
- Apache-2.0
Extended access
Why this level
- The CLI runs a script across checkouts, pushes branches and creates PRs, with optional automatic merging.
Install
Manual install
brew install --cask lindell/multi-gitter/multi-gitterFirst Install method, Homebrew.
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The CLI runs a script across checkouts, pushes branches and creates PRs, with optional automatic merging.
This is third-party code. Review the repository files before installing.
What it does
multi-gitter applies a prepared script across selected repositories, creating pull requests when the script succeeds and changes files. It fits repeated dependency or configuration updates. Users can track requests and merge CI-passing changes under a chosen policy. Scope, branch and commit details are explicit. An agent can prepare the script and inspect a trial before broad rollout.
Who it is for. Multi-repository maintainers rolling out one reviewed change through separate pull requests.
Good fit when
- A shared configuration file needs updating across projects.
- The same replacement or dependency bump affects many repositories.
- Each project needs its own diff and CI check.
- A rollout needs bulk pull-request status tracking after a trial.
Not a fit when
- The script is untested on one repository and may change unrelated data.
- The token covers the organization but targets were not checked.
- Automatic merging is prohibited but enabled in configuration.
Example request
Prepare a shared-file update for two test repositories and inspect a dry-run without creating PRs.Limitations
A token needs repository-listing and pull-request rights; scope it to selected projects. Dry-run prevents pushes and PR creation but still executes the script, so inspect all possible external side effects first. Interpreted scripts run from each repository directory and need a valid absolute path. Automatic merging relies on platform checks and does not replace substantive review of the proposed changes.
How to disable. Stop the rollout and inspect existing branches and PRs. Disable auto-merge and revoke unused credentials separately.
FAQ
When is a pull request created?
When the script exits zero and changes files. Review each repository diff.
Does dry-run execute the script?
Yes. It prevents pushes and PRs, so the script itself must be safe to trial.
Why use an absolute script path?
The working directory changes per repository; an absolute path locates the same script.
How should I supply a token?
Use the platform’s environment variable, keeping it out of arguments and reports.
Can reviewers merge manually?
Yes. Leave auto-merge disabled when separate approval is required.
Discussion
No questions or reviews yet.
Related
CLI toolsrelease-it combines version changes, Git tags and package publishing in a configurable release workflow with a preview mode.
A local gate in front of git push: the branch goes through review, tests, docs and lint in a separate worktree before it reaches the remote with a PR
A Git merge driver and MCP server that compares functions and classes and removes false conflicts from parallel agent edits
A GitLab MCP with 86 tools: issues, merge requests, pipelines, wikis and files, a read-only mode and a launch both locally and remotely with OAuth
A pattern library and skill set for recurring agent loops: issue triage, dependency cleanup, PR babysitting
Nx CLI adopts npm, pnpm or yarn scripts, so teams introduce shared monorepo checks gradually while retaining their commands.
README in short
Multiple Git platforms and configuration files are supported. Command flags override explicitly selected configuration files.