Adopt mob.sh within workstation-setup as a tool for facilitating handover between engineers during a remote pairing session.
Background
Of the two primary forms of pairing (driver/navigator, ping pong), ping pong pairing does a good job of keeping both members of a pair active at the keyboard. Since the pandemic and the shift to remote pairing, it's become more difficult to rotate quickly, and many pairs have moved away from ping pong pairing. A few different tools have been created (both inside and outside of Labs) to help ease the pain of "handover" (ie, the process of shipping the current state of the code to the other person). mob.sh is the most mature tool that I've seen that helps minimize the cost of handing off code between drivers in a remote pairing situation.
How does it work?
mob.sh manages the entire flow from creating a temporary git branch for development, to pushing code to that branch, to pulling the latest code, to preparing/rebasing/squashing all commits for commit/merge to a main trunk branch, to cleaning up temporary branches after they're no longer necessary. The process is as follows, assuming that two developers Carola and Maria are starting from a main branch:
The main commands used in the above flow are mob start, mob next, and mob done. Each one of these commands is making a few calls to git underneath the hood, and managing its state. (There's a video of this in action on the mob.sh website, if you're curious about how it works.) The final step, mob done, will do a soft reset to the state before the first mob start was run, rebasing as necessary on the parent branch, so as to put the pair in good shape to run git commit.
Altogether, mob.sh is a fairly lightweight CLI tool that helps to minimize the friction of remote handover, thereby creating an environment in which pairs or mobs can adopt ping pong pairing more easily.
Proposal
Adopt mob.sh within
workstation-setup
as a tool for facilitating handover between engineers during a remote pairing session.Background
Of the two primary forms of pairing (driver/navigator, ping pong), ping pong pairing does a good job of keeping both members of a pair active at the keyboard. Since the pandemic and the shift to remote pairing, it's become more difficult to rotate quickly, and many pairs have moved away from ping pong pairing. A few different tools have been created (both inside and outside of Labs) to help ease the pain of "handover" (ie, the process of shipping the current state of the code to the other person). mob.sh is the most mature tool that I've seen that helps minimize the cost of handing off code between drivers in a remote pairing situation.
How does it work?
mob.sh manages the entire flow from creating a temporary git branch for development, to pushing code to that branch, to pulling the latest code, to preparing/rebasing/squashing all commits for commit/merge to a main trunk branch, to cleaning up temporary branches after they're no longer necessary. The process is as follows, assuming that two developers Carola and Maria are starting from a
main
branch:The main commands used in the above flow are
mob start
,mob next
, andmob done
. Each one of these commands is making a few calls to git underneath the hood, and managing its state. (There's a video of this in action on the mob.sh website, if you're curious about how it works.) The final step,mob done
, will do a soft reset to the state before the firstmob start
was run, rebasing as necessary on the parent branch, so as to put the pair in good shape to rungit commit
.Altogether, mob.sh is a fairly lightweight CLI tool that helps to minimize the friction of remote handover, thereby creating an environment in which pairs or mobs can adopt ping pong pairing more easily.