I’m sure you are familiar with the term WIP, just in case Work In Progress. It relates to something that is not finished yet, there’s a bit more way to go before completing it. I’ve been using Trunk-based development for some time now. We commit and push straight to master at FMP.

Crazy, right? I had been doing my branches and Pull requests in Github for a few years. One day someone came:

We are going to end with Pull requests, if we do Pair programming we should push to master, without a formal Code review process.

I must admit, I disliked the idea. For me Pull Requests were the best way to share knowledge in an offline way, it was a way to get feedback from great developers and a way to keep the quality of our code as high as possible.

After more than a year of Trunk-based development, now it is my favourite way of working. There are many challenges a team faces when pushing straight to master, it is a cultural change and there is a massive change in the way the team operates. One of the aspects of working in master is keeping it in a healthy state.

We were quite lucky the day Dennis Ideler joined our team, his massive sense of professionalism meant that I was going to learn loads. One of the areas has been Version Control.

The following happened not long ago. That day I had been doing Pair programming for the whole day, it was late and there were some pending changes in my computer. My colleague wanted to get these changes in Github so he could continue working the day after from his computer. Although the changes were incomplete, tests were passing and I really wanted to go home. Once more, my lazy side showed its ugly face:

Let’s create a branch, and commit this changes as “WIP”.

The day after, we started by getting the branch in my colleagues computer and merging it into master. My lovely “WIP commit” went into master. That moment could have easily gone by, but suddenly I overhead:

Why is this WIP in master? This should have never gotten into master.

The shame and guilt came quickly but with my cheeks flushed, I asked why that was a problem. We have a chat about how every commit needs to be a fully working part. When we try to solve a problem we break that problem into subproblems. It is ok to commit a finished solution to a subproblem, but not Work in progress. Working in master means that every commit is pushed to live in a matter of a few minutes. Also everything we commit will be pulled by dozens of devs, they need to get something working, not something in progress.

I asked how he could have solved the problem:

1. Create a branch: Name it with the name of the ticket (if you have one) and with the thing that is “In Progress”.

git checkout -b Ticket123/unfinished-post

2. Commit the changes in this branch: Give some context to help your colleague remember and push the new branch to your VCS.

git commit
git push origin Ticket123/unfinished-post

3. In the other work station, pull latest master and get the branch.

git fetch
git rebase master
git checkout Ticket123/unfinished-post

4. Uncommit the “Work In progress”, with the following command:

git reset --soft HEAD^

I have that command with an alias in my gitconfig git uncommit. That will move the branch pointer to the previous commit but leaving the working directory state unchanged.

5. Switch to master:

git checkout master

You will find the changes that you did in the other computer, pending to be staged in master. Now you can continue the work and finish the WIP. Then your changes can go into master.

Thanks for reading and thanks to Dennis Ideler for being a mentor on many things during this time in Findmypast.