Add https://mob.sh remote handover tool to common git config #332
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.