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

If you often end up in messy situations 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 using a temporary branch in origin as synchronization point. 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.

Git – 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 increase the risk of messing up and that the team loses focus.

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!

There are a lot of different timer apps out there, I’m building a timer app called Remobster, if you are interested in checking it out, sign up for the waitlist to become an early access user 🙂

Other alternatives are:

• http://timer.mob.sh
• http://remotemob.io
• and many more..

5. Time for the git 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 make the handover to the next driver as fast and smooth as possible.

The driver then pushes the changes:

git push origin wip

Next driver

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

git pull origin wip

and then follow steps 4 and 5. And then you just repeat!

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 fulfills 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 r and 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 🎉

Original post