larlet-fr-david-cache/cache/13d9da5621e5616aee2248696390c693/index.md

title: Telling stories through your commits
url: https://blog.mocoso.co.uk/talks/2015/01/12/telling-stories-through-your-commits/
hash_url: 13d9da5621e5616aee2248696390c693

<p>This is a short talk that I have given on a variety of occasions about
how you can use your source control commit messages to keep track of the
intent of your code changes and make it easier to keep changing your
project in future.</p>

<p>The transcript below is from the version of the talk that I gave at the
<a href="http://2016.theleaddeveloper.com/talks#joel-chippindale">Lead Developer
Conference</a> in
London in June 2016.</p>

<h2 id="transcript">Transcript</h2>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.001.png" alt="opening slide"/></p>

<p class="transcript">I am Joel Chippindale and I have been the CTO at FutureLearn for the
last few years and I am here to talk to you about telling stories
through your commits.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.002.png" alt="opening slide"/></p>

<p class="transcript">If we have a successful software development project then our key
challenge, as lead developers, is to manage complexity because projects
can get very complex very quickly even within quite small teams.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.003.png" alt="opening slide"/></p>

<p class="transcript">As lead developers we, and our teams, spend a lot of time thinking about
this. We think about the naming of methods and functions and variables
and…</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.004.png" alt="opening slide"/></p>

<p class="transcript">we think about our code design.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.005.png" alt="opening slide"/></p>

<p class="transcript">We probably spend a lot of time refactoring code. Taking code that works
and making it simpler to understand.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.006.png" alt="opening slide"/></p>

<p class="transcript">And probably most of your teams are spending a good proportion of their
time writing automated tests and that allows your teams to have the
confidence to keep changing the software but also helps to document what
the code is supposed to do.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.007.png" alt="opening slide"/></p>

<p class="transcript">All these tools and techniques help communicate the intent of our
software and if we want to keep changing it we need to understand this
intent.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.008.png" alt="opening slide"/></p>

<p class="transcript">There is one tool that we under utilise in our communities for
communicating our intent and that is our version control system. All the
examples in this talk use git but the principles apply to whatever
system you are using.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.009.png" alt="opening slide"/></p>

<p class="transcript">Our commit history has some very special properties which make it
particularly useful for documenting intent.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.010.png" alt="opening slide"/></p>

<p class="transcript">It is kept forever.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.011.png" alt="opening slide"/></p>

<p class="transcript">It is always up to date and this almost certainly not true of most of
the documentation you have, perhaps in a wiki or even in code comments.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.012.png" alt="opening slide"/></p>

<p class="transcript">And, this may come as a surprise to some of you, it is searchable. Git
doesn’t make this obvious so here are some commands that you may find
useful.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.013.png" alt="opening slide"/></p>

<p class="transcript">You can search all the contents of all your commit messages.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.014.png" alt="opening slide"/></p>

<p class="transcript">You can search all the contents of all the code changes in your commits.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.015.png" alt="opening slide"/></p>

<p class="transcript">And you can find out where each line of code was last changed…</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.016.png" alt="opening slide"/></p>

<p class="transcript">…giving you output like this.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.017.png" alt="opening slide"/></p>

<p class="transcript">It is these properties that allow Mislav Marahonić to say that, “Every
line of code is always documented”. If every line of code is documented
how do we make sure that this documentation tells a useful story to us
and our teams about that line of code?</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.018.png" alt="opening slide"/></p>

<p class="transcript">I will share 3 principles with that will help you with this.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.019.png" alt="opening slide"/></p>

<p class="transcript">Firstly and most importantly make atomic commits. Make your commits
about a single change to your code base.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.020.png" alt="opening slide"/></p>

<p class="transcript">To illustrate why this is important I am going to share a git horror
story with you. This is from a project which I am responsible for. Bug
fixes? Which ones? How many? We have no idea. And a Wordpress update.
Those of you who are laughing are probably doing so because there are
175 thousand lines of code changes in this commit. Reverse engineering
this commit to find out what happened is very hard.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.021.png" alt="opening slide"/></p>

<p class="transcript">Let us imagine an alternate history where this commit had been split
into atomic commits.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.022.png" alt="opening slide"/></p>

<p class="transcript">Here we might have a Wordpress update commit containing the vast
majority of those 175k lines of changes and then 8 separate commits each
one about a single bug which is easy to understand.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.023.png" alt="opening slide"/></p>

<p class="transcript">When I talk about this, I am often asked how big an atomic commit should
be? In our industry we generally make our commits too big so it is worth
thinking about a minimum viable commit. What’s the smallest useful
change that you can make to your codebase?</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.024.png" alt="opening slide"/></p>

<p class="transcript">Another useful rule of thumb is to avoid needing ‘and’ in your commit
messages. If you did ‘A’ and ‘B’ maybe they are two separate changes.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.025.png" alt="opening slide"/></p>

<p class="transcript">Second principle: write good commit messages.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.026.png" alt="opening slide"/></p>

<p class="transcript">That’s very easy for me to say so I will take you through a template to
give you more of an idea of what I mean.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.027.png" alt="opening slide"/></p>

<p class="transcript">Short one line title because you view your commits in lists and a longer
description if you need it.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.028.png" alt="opening slide"/></p>

<p class="transcript">An explanation of why the change is being made. If people want to know
how they can change this in future then they need to know what the
intention of this change was.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.029.png" alt="opening slide"/></p>

<p class="transcript">Lastly, when you make this commit, you know more about why you are
making this change and how you are fixing or improving this thing than
anyone else ever will and so it can be useful to outline some of the
context and alternative approaches considered.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.030.png" alt="opening slide"/></p>

<p class="transcript">To make this more concrete, here is an example of a commit message from
one of the other projects I am responsible for. You can see the one line
title, you can see a link to our bug tracking system, you can see an
explanation of the quirks of Outlook and why we are making this
particular change and a link to a blog post which explains more about
the problem. This is gold dust for people going back and trying to work
out why the CSS in our project is in the particular state it is in.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.031.png" alt="opening slide"/></p>

<p class="transcript">Third principle: revise your development history before sharing. We all
know that once commits are on master, or once they are deployed, you
don’t want to change them out from underneath people. But, in your
development branches, it can be much more useful if they tell a story
about what you intended to do instead of a blow by blow account of all
the missteps you took along the way.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.032.png" alt="opening slide"/></p>

<p class="transcript">There’s a tool for this, git rebase interactive…</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.033.png" alt="opening slide"/></p>

<p class="transcript">…and this allows you to remove, reorder, edit, merge and split
commits. Essentially with this tool your development branches are
infinitely malleable.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.034.png" alt="opening slide"/></p>

<p class="transcript">To give you a quick example. Imagine I have added Foo and made a commit,
removed Bar and made a commit and then I have spotted a typo in the
first commit so I make a new commit to fix the typo. That’s just noise
for other people. No one cares about the fact that I didn’t get the
first commit right first time.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.035.png" alt="opening slide"/></p>

<p class="transcript">We can use git rebase interactive to merge the first and third commits
and tell a simpler story about what we are trying to do.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.036.png" alt="opening slide"/></p>

<p class="transcript">So three principles. 1. Make atomic commits. 2. Write good commit
messages and 3. Revise your development history before sharing</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.037.png" alt="opening slide"/></p>

<p class="transcript">This is a quote from someone who joined our team recently which I hope
will help persuade you of the benefits of taking this approach.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.038.png" alt="opening slide"/></p>

<p class="transcript">Perhaps you are sitting here, as lead developers, thinking this sounds
like a really good idea. How am I going to take this back to my team on
Monday? How am I going to persuade them to adopt these practices that
seem like they have pay off months or even years down the line perhaps
for other developers on the team?</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.039.png" alt="opening slide"/></p>

<p class="transcript">Won’t it take a huge amount of discipline?</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.040.png" alt="opening slide"/></p>

<p class="transcript">I think the key is that all these practices make things simpler for
individual developers in your team right now.</p>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.041.png" alt="opening slide"/></p>

<div class="transcript">
  <p>Let’s go back over the principles.</p>

  <p><strong>Make atomic commits</strong></p>

  <p>This is about making sure that you are making one change at a time to
your code. This makes it simpler to work on.</p>

  <p><strong>Write good commit messages</strong></p>

  <p>If you can write down what you are trying to do in the particular change
that you are making then you are half way there already and it is a
really valuable discipline for you and your teams to get into.</p>

  <p><strong>Revise your history before sharing</strong></p>

  <p>If your development branch tells a good story about what you did then it
is easier for you to understand what you did and whether it solves the
problem you had and also it is easier to share with others, perhaps in a
pull request, to get feedback. All these practices making things easier
now for your teams.</p>
</div>

<p class="slide"><img src="https://blog.mocoso.co.uk/assets/telling-stories-through-your-commits/slides.042.png" alt="opening slide"/></p>

<p class="transcript">Thank you for your time.</p>