remotemobprogramming/mob: Fast Git handover for remote teams

mob solves the handoff gap in remote pairing

mob addresses a specific friction point in remote pair and mob programming: the code has changed, but the next person needs to continue without taking ownership of an unfinished commit on the main branch. The README describes mob as a tool for fast Git handover and identifies its users as remote pairs and groups working together. It is not a source editor, chat application, screen-sharing service, or continuous integration system. Its responsibility is the Git ceremony around a session.

The central design choice is to keep unfinished work on a temporary WIP branch and reserve the base branch for the completed result. The documented workflow uses `mob start`, `mob next`, and `mob done`. That gives a team a small command vocabulary for beginning work, passing it to another participant, and bringing the accumulated changes back to the base branch's staging area. This is useful when several people share the same working tree over time but do not want every intermediate attempt to become a permanent commit.

The repository also describes a shared team timer at `timer.mob.sh`. The timer supports the session rather than the Git mechanics, so it should be treated as an accompanying feature. The README also points to VSCode integration, but that extension is a separate integration and the repository documentation does not define its behavior. The core tool remains the Go executable described in the README.

Temporary WIP branches carry unfinished changes

The documented data flow begins on the base branch. `mob start` moves the session to a separate branch, shown in the example as `mob/main`, so subsequent edits are associated with temporary WIP work rather than directly with `main`. The branch is intended to be a handover point. A participant can add files or modify files, then use `mob next` to hand the state to the next person.

The example makes the transfer visible. Carola starts from `main`, creates `work.txt` on `mob/main`, and runs `mob next`. Maria starts her own session, reads the file, appends ` world`, and hands it over again. Carola then reads `hello world`, appends an exclamation mark, and runs `mob done`. At that point, the changes are moved to the staging area of the base branch. The final commit is made explicitly with Git, as shown by `git commit -m "create greeting file"`, followed by `git push`.

That sequence explains why `done` is not the same as committing. It stages the accumulated WIP changes in the base branch, leaving the participant to inspect and commit the result. The repository's basic command list also includes `reset`, which removes local and remote WIP branches, and `clean`, which removes orphan WIP branches. Those commands are useful for cleanup, although the README does not document their prompts, safety checks, or recovery behavior.

Installing mob across supported package managers

The recommended installation method is the install script. The README says it works for macOS, Linux, and Windows in Git Bash. Run the following command in a shell where downloading and executing the script is acceptable for your environment. The reader should see the script install the `mob` command, then should confirm that the executable is available on `PATH`.

curl -sL install.mob.sh | sh

For macOS users, the README also documents Homebrew. This command installs the package named `mob`.

brew install mob

On Windows, the documented alternatives are Scoop and Chocolatey. The commands are separate installation choices, not steps that must all be run.

scoop install mob

choco install mob

Arch Linux users can use the documented `yay` package, and Nix users can declare `mob` in `environment.systemPackages`. The repository also lists a pkgsrc route. These alternatives matter because `mob` is distributed through several package ecosystems rather than only as a source checkout.

The README has a version inconsistency that should be checked before using the Go installation path. It shows `github.com/remotemobprogramming/mob/v4@latest`, while the repository `go.mod` declares module path `github.com/remotemobprogramming/mob/v5` and Go 1.22. The README does not explain that discrepancy. A user choosing `go install` should verify which module path and release are intended rather than copying both paths together.

A first session with start, next, and done

Begin in a checkout and switch to the base branch. The README example shows `main` as the starting branch, then uses `mob start` to enter `mob/main`. The following commands form a complete handover sequence. Because the repository does not include the example's console output, the observable result to check is the branch transition and the presence of the edited file in the next session.

main $ mob start
mob/main $ echo "hello" > work.txt
mob/main $ mob next
main $ mob start
mob/main $ cat work.txt
mob/main $ echo " world" >> work.txt
mob/main $ mob next
main $ mob start
mob/main $ cat work.txt
mob/main $ echo "!" >> work.txt
mob/main $ mob done
main $ git commit -m "create greeting file"
main $ git push

The first participant starts a session and creates a file. The second participant starts from the base branch and retrieves the file through the WIP branch. The final participant adds more content, completes the handover with `mob done`, inspects the staged result on `main`, commits it, and pushes. The README presents this as the normal lifecycle rather than as a one-time demonstration.

For teams that want a timer at the beginning, the command syntax also documents `mob start [<minutes>]`. The README does not explain timer duration defaults, notifications, or browser behavior, so those points should be verified in the tool's help output or project documentation before becoming part of a session policy.

The compact CLI leaves several Git details to the operator

mob is deliberately narrow in its primary interface. The README says that only three commands are needed for the core loop, and the basic command list groups start, next, done, reset, and clean under a CLI-oriented workflow. This makes the tool suitable for teams that want a consistent handover procedure, but the operator still participates in Git operations such as reviewing the staged result, choosing a commit message, and pushing the branch.

The Snap package is explicitly marked experimental and has a known limitation: `ssh-agent` does not work. The README gives a connection command after installation, but that limitation remains relevant even after the package is connected. A team whose remote workflow depends on an SSH agent should choose another installation route or confirm that the Snap environment can perform its required Git authentication.

The timer service and VSCode integration add adjacent conveniences, but the README does not specify offline behavior, timer synchronization, or conflict handling. It also does not explain how the VSCode extension behaves when multiple people use the same branch. The repository layout indicates dedicated Go packages for Git, configuration, timer, HTTP, and work directories, but their internal behavior is not documented in the README excerpt. Claims about automatic conflict recovery would therefore exceed what the repository documentation establishes.

mob versus manual Git handover

A direct alternative is to manage the same temporary branches manually with Git. The difference is not the underlying repository model. Both approaches can use a base branch, a WIP branch, incremental edits, and a final commit. mob adds a command layer that standardizes `start`, `next`, and `done`, and its documentation supplies a shared handover pattern for remote sessions.

A manual Git workflow gives the operator more visible control over branch creation, pushes, rebases, conflict resolution, and cleanup. It also requires the team to document or remember the procedure. mob reduces the number of repository operations that participants need to remember, but the README does not claim to eliminate Git conflicts or to provide a hosted collaboration environment. The trade-off is therefore between convention and explicitness.

Other tools could provide broader remote pair programming features, but the README does not name a comparable project or define interoperability. The documented comparison is between mob and manual Git handover: choose mob when a repeatable CLI convention matters, and retain a manual workflow when branch topology, authentication, or recovery must remain visible and customizable at every step.

MIT licensing and recent project activity

The repository identifies mob as an open source command-line tool written in Go and lists the MIT license. The license file is present at the repository root. MIT licensing defines the project's distribution terms, but this review does not assess how an organization applies the license in its own distribution process.

The repository is not archived. Its last push was on 2026-04-21. The release history lists version `5.4.2` dated 2026-01-26, `5.4.1` dated 2025-11-25, and `v5.3.3` dated 2024-10-18. The version labels are inconsistent across the release history and the Go installation examples, so users should verify the exact release and module path before automating installation. The README points to `mob.sh`, the release page, and the GitHub repository, but it does not document a rollback procedure or a compatibility matrix for operating systems and Git versions.

For a team adoption decision, the practical maintenance question is change control rather than license complexity. The team should record which `mob` release it installs, confirm the command behavior on its Git remotes, and decide how it will handle branches left behind after an interrupted session. Those checks are more relevant to adoption than assuming that a newer release preserves every undocumented local procedure.

Editorial conclusion

Adopt mob when the team wants a small, Git-centered handover command with temporary WIP branches and a shared timer. Do not adopt it as a replacement for a full collaboration platform or Git training system. Verify branch naming, remote Git access, the selected installation route, and the documented v4 and v5 module path discrepancy first.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. remotemobprogramming/mob on GitHub