# rebase-editor: a terminal sequence editor for git rebase -i

> rebase-editor replaces the text editor that git opens for an interactive rebase with a small terminal UI written in TypeScript, so you reorder commits, switch pick to squash or drop, and reword messages with the keyboard instead of a modal editor. It is fast to learn and, in the author's words, the safety net is git reflog.

**sjurba/rebase-editor** — Simple terminal based sequence editor for git interactive rebase.

- Repository: https://github.com/sjurba/rebase-editor
- Stars: 666 · Forks: 20
- Language: TypeScript
- License: not declared
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/sjurba-rebase-editor

## The editor git opens, replaced by a terminal UI

rebase-editor is a simple terminal based sequence editor for git interactive rebase. It is written in TypeScript, published to npm, and it uses terminal-kit for the interface.

The problem it addresses is specific. When you run git rebase -i, git opens your sequence editor on a todo file listing the commits to be replayed, and the stock experience is your full text editor, with its own key bindings, its own file dialogs, and a modal model that is a poor fit for a screen that is essentially a list of one-word commands. rebase-editor puts a small purpose built interface in that slot.

What the interface shows is the standard interactive rebase file that git creates, plus some extra command information in the comments. The comments are where the editor earns its keep: instead of you having to remember which letter means what, the file itself tells you the available commands. The commands are the git ones, so p and r and e and s and f and b and d, standing for pick, reword, edit, squash, fixup, break and drop. When you change the current line's action, it changes to the corresponding action.

The one gap the README calls out is that the x, exec command is not supported. A todo list that relies on exec to run a command between commits therefore cannot be expressed here.

Everything is keyboard driven, with the movement keys mapping onto the same ideas as a text editor. UP and DOWN move the cursor between lines, SHIFT with the arrows selects, RIGHT and CTRL_DOWN move the current line down one position, LEFT and CTRL_UP move it up, HOME, END, PAGE_UP and PAGE_DOWN move and select with SHIFT, z and CTRL_Z undo, Z and CTRL_SHIFT_Z redo, ENTER and q save and quit, and ESC and CTRL_C abort.

## Reword mode edits the commit message in place

The reword command gets its own mode. Pressing r on a reword line, or r again on a line that is already marked reword, opens an inline message editor, and the full commit message is fetched from git and shown for editing.

The reword mode keys are a small text editor: ENTER inserts a newline, ESC saves and exits reword mode, CTRL_Z restores the original message for the editor session, CTRL_C cancels and restores the original message, LEFT and RIGHT move the cursor, UP and DOWN move across lines, HOME and END go to the start and end of the current line, SHIFT with the arrows extends the selection, CTRL_A selects all text, CTRL_K deletes the current line, and BACKSPACE and DELETE delete a character.

That the message is fetched from git rather than edited in the todo file is the detail that makes this usable. The todo file only carries the first line of a message, so editing it in place would silently discard the body. Fetching the whole message and writing it back means a reword in this editor behaves like a reword in your normal editor, which is the point of having it at all.

If you want your usual editor for a single run, the README points at the GIT_SEQUENCE_EDITOR environment variable:

```
    GIT_SEQUENCE_EDITOR="vi" git rebase -i master
```

So the tool is a default you can override per invocation, which is a sensible escape hatch when a rebase needs an unusual edit.

## Installing it and pointing git at it

Installation is two commands. Install the package globally with npm, then tell git to use it as the sequence editor:

```bash
     npm install -g rebase-editor
     git config --global sequence.editor rebase-editor
```

The README notes that Node.js 18 or later is required, and that it also works with yarn, via yarn global add rebase-editor. The package.json records the same requirement as engines with node >=18.0, and the binary is registered under the name rebase-editor, pointing at dist/index.js.

Uninstalling is the mirror image of the install, npm remove -g rebase-editor followed by git config --global -, which unsets the sequence.editor key you set.

The command line arguments exist so you can pass options into the git configuration, since git invokes the editor with the todo file as its argument. The flags are -s or --status to print a status line on top, described as useful for debugging custom key maps, -k or --keys to set a custom keybinding file, -c or --color for colorful output, and -m or --marker to set the marker used for selected lines, plus --no-alternate-screen to disable the alternate screen.

The color argument takes an optional extra value, a comma separated string of terminal-kit style characters, and it can colour three things: the line action, the hash, and the message. An empty string means no special color, and the examples are things like -c ^r,^y,^b for red, yellow and blue.

The marker option sets the string drawn next to selected lines, any string such as '> ' or a terminal-kit style character. The default is '^!', an inverse marker, except on Windows where that does not work and the default becomes yellow, '^Y'.

Putting it together, the README gives this as a complete configuration:

```bash
  git config --global sequence.editor "rebase-editor -s -c -m '> ' -k ~/.rebase-editor-keybindings.json --"
```

The note at the end explains the trailing dashes: when using command line arguments the command should end with -- to separate your arguments from the filename of the rebase file.

## Key bindings are data, and you can rewrite them

The key bindings are not hard coded. A bindings file can be JSON or a node module exporting a simple object, and the special keys are the ones terminal-kit defines. The -k and --keys option points at that file, which is how the configuration example above wires in a personal ~/.rebase-editor-keybindings.json.

The default set is a JSON object mapping key names to action names. UP and DOWN are up and down, LEFT and CTRL_UP are moveUp, RIGHT and CTRL_DOWN are moveDown, and the SHIFT combinations map to the select variants, selectUp, selectDown, selectPageDown, selectPageUp, selectHome and selectEnd. The letters map to the git actions, pick, reword, edit, squash, fixup and drop, and BACKSPACE and DELETE are also mapped to drop, which is a shortcut worth knowing about and also a hazard worth knowing about. Then there is undo, redo, quit, and abort.

Reword mode has its own namespace, in a rewordMode field of the same file, with the reword prefixed names such as rewordDone, rewordBackspace, rewordEnter, rewordLeft, rewordSelectAll, rewordDeleteLine, rewordUndo and rewordCancel.

Two platform notes come out of this. On macOS, not all key combinations work by default, and most notably no modifier keys work with UP and DOWN, with SHIFT, CTRL, ALT and META all failing, while Fn translates to PAGE_UP and PAGE_DOWN, which is why the author fell back to the LEFT and RIGHT combinations for Mac and expects you to configure your terminal if you want more. CMD-Z and CMD-SHIFT-Z do not work either, which is why plain z and Z do undo and redo. And the platform table says Mac yes, Linux yes, and Windows yes, but not Git Bash.

If you get it wrong, the README has a short answer for that too, in the section headed Made a mistake, which says git reflog is your friend.

## Where a terminal sequence editor stops being useful

The first limitation is that this is an interactive program, not a tool for a pipeline. Every action in it depends on a human pressing a key, and the README documents no batch or non interactive mode, no flag to apply a todo list without opening the interface. If your rebase process is scripted, or runs in CI, or is part of a release checklist, this is the wrong tool and git rebase with an editor that exits immediately is the right one.

The second is the exec gap. Since the x, exec command is not supported, any workflow that relies on running a command between commits, for instance to regenerate code or re-run a migration, has to be moved outside the rebase. That is a real constraint for teams whose history rewriting includes verification steps.

The third is terminal fidelity. The editor depends on what the terminal reports about modifier keys, and on macOS the README is explicit that most of them do not arrive. On Windows the inverse marker does not render, which is why the default marker changes there. In a remote session, over a terminal multiplexer, or inside an editor's built-in terminal, key delivery can differ from a local terminal, and the symptom is a key that does nothing.

The alternative is to keep using a plain text editor on the todo file. The git way of working is to set sequence.editor to your editor of choice and edit a list of short lines. rebase-editor's advantage over that is the on screen help and the key based reordering without a modal editor, and its cost is a Node.js runtime and a program that must be launched for every rebase, on a machine where the tool may not be installed if you are on someone else's machine or a fresh container.

## Conclusion

rebase-editor suits a developer who does interactive rebases often enough that the round trip to a modal text editor is the annoying part, and it suits a scripted rebase workflow poorly, since it is an interactive program with no documented non interactive mode. Before adopting it, check that your terminal reports the keys it expects, particularly on macOS where the README notes that modifier combinations do not work with the arrow keys by default, and note that the exec command is not supported, so a todo list that relies on exec has to be run another way. The npm package is published under the ISC licence, the last push was on 2026-09-03, and the newest release is v2.2.0 from 2026-04-16.

## FAQ

### How do I install rebase-editor and make git use it?

Run npm install -g rebase-editor, then git config --global sequence.editor rebase-editor. Node.js 18 or later is required, and yarn global add rebase-editor also works. To undo it, run npm remove -g rebase-editor and git config --global -.

### Which rebase commands does rebase-editor support?

It supports the git commands pick, reword, edit, squash, fixup, break and drop, shown as the letters p, r, e, s, f, b and d. The README notes that the x, exec command is not supported.

### Can I use my own editor for one rebase with rebase-editor installed?

Yes. The README shows the GIT_SEQUENCE_EDITOR environment variable, so GIT_SEQUENCE_EDITOR="vi" git rebase -i master uses your editor for that run only, without changing the global sequence.editor setting.

### How do I change the key bindings in rebase-editor?

Point the -k or --keys option at a JSON file or a node module that exports an object, for example in the git config line for sequence.editor. The default mappings are shown in the README, and reword mode keys live in a rewordMode field of the same file.

### Does rebase-editor work on Windows and macOS?

The platform table lists Mac as supported, Linux as supported, and Windows as supported but not Git Bash. On macOS the README warns that modifier keys do not work with the arrow keys by default, which is why the LEFT and RIGHT combinations are used as a fallback.

## Sources

- [Issues](https://github.com/sjurba/rebase-editor/issues)
- [README](https://github.com/sjurba/rebase-editor/blob/master/README.md)
- [Releases](https://github.com/sjurba/rebase-editor/releases)
- [sjurba/rebase-editor on GitHub](https://github.com/sjurba/rebase-editor)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sjurba-rebase-editor