A place to cache linked articles (think custom and personal wayback machine)
選択できるのは25トピックまでです。 トピックは、先頭が英数字で、英数字とダッシュ('-')を使用した35文字以内のものにしてください。

index.md 15KB

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

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.

The transcript below is from the version of the talk that I gave at the Lead Developer Conference in London in June 2016.

Transcript

opening slide

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.

opening slide

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.

opening slide

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…

opening slide

we think about our code design.

opening slide

We probably spend a lot of time refactoring code. Taking code that works and making it simpler to understand.

opening slide

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.

opening slide

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.

opening slide

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.

opening slide

Our commit history has some very special properties which make it particularly useful for documenting intent.

opening slide

It is kept forever.

opening slide

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.

opening slide

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.

opening slide

You can search all the contents of all your commit messages.

opening slide

You can search all the contents of all the code changes in your commits.

opening slide

And you can find out where each line of code was last changed…

opening slide

…giving you output like this.

opening slide

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?

opening slide

I will share 3 principles with that will help you with this.

opening slide

Firstly and most importantly make atomic commits. Make your commits about a single change to your code base.

opening slide

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.

opening slide

Let us imagine an alternate history where this commit had been split into atomic commits.

opening slide

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.

opening slide

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?

opening slide

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.

opening slide

Second principle: write good commit messages.

opening slide

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.

opening slide

Short one line title because you view your commits in lists and a longer description if you need it.

opening slide

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.

opening slide

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.

opening slide

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.

opening slide

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.

opening slide

There’s a tool for this, git rebase interactive…

opening slide

…and this allows you to remove, reorder, edit, merge and split commits. Essentially with this tool your development branches are infinitely malleable.

opening slide

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.

opening slide

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.

opening slide

So three principles. 1. Make atomic commits. 2. Write good commit messages and 3. Revise your development history before sharing

opening slide

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.

opening slide

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?

opening slide

Won’t it take a huge amount of discipline?

opening slide

I think the key is that all these practices make things simpler for individual developers in your team right now.

opening slide

Let’s go back over the principles.

Make atomic commits

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

Write good commit messages

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.

Revise your history before sharing

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.

opening slide

Thank you for your time.