The ritual of handover in mob programming (or pair or other software teaming techniques) are crucial for keeping the focus and pace.

If you often end up in messy siutations caused by git, this is the guide for you!

In a remote mob programming session the most common way of doing the handover is via git. There is even a good tool built for this called mob.sh. However, in this post, we will focus on how to do it ourselves.

Keep it simple

I cannot stress this enough. Keep it simple should be the leading idea when doing handovers. As soon as you try to get fancy with git, you have a higher risk of messing up and push the entire mob into a void.

1. Create a branch named wip

The name is really not that important, you can call it mob or asdf.The important thing it should be easy to say and type, and it should be short. This makes it easier for everyone in a remote call to hear the name of the branch and be able to check it out. To create a branch:

git switch -c wip

2. Push the branch

The first driver of the session creates the branch and pushes it.

To push the branch write:

git push origin wip

3. Everyone else switch to the wip branch

Now it’s a good time for everyone else in the rotation to fetch the wip branch to make it easier during handovers.

Simple write the following command:

git switch -c wip origin/wip

4. Code

Start the timer and start implementing the code your mob session is about to code.

If you want to use the best remote mob programming timer out there we recommend Remobster!

5. Handover!

When the time is up for the current driver, it’s time to handover to next driver.

First add all changes in the repo:

git add .

Then commit the changes:

git commit -m wip

The reason we set the message to wip, is to not complicate things and make the handover to the next driver as smooth as possible.

The driver then pushes the changes:

git push origin wip

Next driver pull the latest changes

Now the next driver can saftley continue. The only thing the new driver needs do to is

git pull origin wip

and then follow steps 4 and 5.

Finish up

When the mob session is happy with the code and wants to deliver it, I recommend squashing all the commits into sane pieces and write good commits messages describing the changes.

This step should also be done together in as many rotations that is needed to create a git artifact that fulfilles your requirements.

In my team we usually do something like this

git rebase -i origin/main

This opens an interactive editor (usually vim) where you can decide what to do with each commit

pick abc1234 wip
pick def5678 wip
pick ghi9012 wip

On the first commit change pick to rand for the other commits change them into f like this

r abc1234 wip
f def5678 wip
f ghi9012 wip

This will let you rewrite the first commit’s message into something better and the other commits will be squash into the first commit, removing their messages.

Read this article to learn how to write great commit messages

When you are happy with your new commit messages, force push the wip branch by:

git push —force origin wip

Then you are done, now you can merge the wip branch into main or open a PR/MR if that is needed in your process.🎉