What to expect: Git handover using mob

Git handover

When using Git handover, the current driver shares their screen and works entirely on their own machine. After their driving time is up, the driver quickly pushes up code changes to a temporary branch. The next driver in turn shares their screen and pulls the in-progress code from the temporary branch. This transition from one driver to the next is known as a handover.

For PubMob sessions, we use the tool mob to reduce transitions to a single command.

How does Git handover work?

For a sample driver session (let's say for three minutes), the next developer in turn:

• shares their screen

• issues the command mob start 3

• listens for direction from the mob

• builds code to support the mob's direction

• issues the command mob next, which passes the driver role to the next developer in turn

The mob start command checks out a work-in-progress (WIP) branch named mob-session, creating it if necessary. The mob next command commits the current changes and pushes the WIP branch. The code can be in any state when mob next is executed; it might not even be compiling.

When the mob is ready to create a commit representing a piece of "done" work, the current driver issues the mob done instead of the mob next command. When mob done is executed, the mob tool squashes all of the many WIP commits and stages the resulting changes on the master branch, then removes the WIP branch as a cleanup step. The team can review what's staged and create a commit as appropriate.

How do I get ready?

When using the mob tool, you have the advantage of working on your own machine, but you'll need to spend a few minutes setting things up.

• You'll need to install the mob tool, using the instructions on its GitHub page. It's a one-command install on the Mac, Windows, or Linux. If you are on Windows, run the installation script in a Git Bash window. For macOS users, it's a single brew install command.

• You'll need to clone the session's repository and ensure you can build / run tests.

• Check the listing for the PubMob session you are joining to see if there is any additional setup information.

• You may also need to provide a GitHub or other repository host login ID to the session lead.

Participants who aren't ready will be asked to fall back to remotely-controlling the machine of your session lead, which is a lot less fun.

One-chance setup / fallback rule

When a PubMob session starts, you should be ready to code. The first time you drive, you'll be asked to do a mob start 5, compile and run tests, make a small change, then do a mob next. If any of these steps fail, your session lead and the other PubMobbers will attempt to help you finish setting up. If you're unsuccessful, you'll be asked to remotely control the session lead's machine for the remainder of the session.

If you have challenges setting up, don't hesitate to solicit help from the session lead before the session begins!

Certain introductory PubMob sessions will set aside time during the session to help everyone get setup up. Look for these if it's your first visit to a PubMob!

Trade-offs for Git handover

Benefits:

• Ability to work in your own preferred IDE under your own OS.

• Ability to use your own keyboard configuration / plugin.

• Rapid handovers.

• No lag while typing.

• Spotty internet connection does not deteriorate your ability to type.

• No keyboard mismatch issues across the wire.

Costs:

• Requires mob tool installation.

• Requires that you can build and run tests locally.

• Requires push access to the Git repository used.

• Occasional need to fix Git out-of-sync problems when protocol not followed.

• Potential dissonance for observers when multiple IDEs / layouts / colors used.

• Handovers can require a few additional seconds to restore any closed files. (This can be overcome by configuring mob to remain on the WIP branch after a handover.)

Git handover with the mob tool is usually ideal for an established and remote development team whose members would already have met the build and Git requirements.

For PubMob use, the costs can represent a significant impact to a session if attendees are not properly prepared.

To prevent unprepared attendees from taking valuable time from a session, we employ a one-chance setup / fallback rule.