larlet-fr-david-cache/cache/3298d68a0ad3d267742d80811213d628/index.md

title: Telling stories with your Git history
url: https://about.futurelearn.com/blog/telling-stories-with-your-git-history
hash_url: 3298d68a0ad3d267742d80811213d628

<p><b>Seb Jacobs, a Developer at FutureLearn, discusses how we maintain a </b><b>useful Git history and outlines five principles we live by when making code commits.</b></p>
<p>Development started on the FutureLearn platform on 2 April 2013 and since that time, our codebase has gone through rapid changes, covering over 10,000 commits.</p>
<p>With a rapidly changing codebase and a growing development team, being able to communicate how and why your code evolves over time is crucial.</p>
<p>In order to manage the complex process of changing coding, we not only believe in having well factored code and tests, but also a simple Git history, which allows us to make informed decisions about future code changes.</p>
<h2>Telling stories with your Git history</h2>
<p><a href="https://github.com/Futurelearn">Our Git history</a> is a living, ever-changing, searchable record that tells the story of how and why our code is the way it is. The ability to document code effectively using Git (or another version control system) is just as important as being able to ship a feature, write clean code or readable tests.</p>
<p>Although your code should be self-documenting, it doesn&#8217;t tell the story of why the code is the way it is or how it came to be.</p>
<p>You may be used to more conventional methods of code documentation such as a Readme or a Wiki, however these forms of documentation can often become out of date.</p>
<p>The other method of code documentation that comes to mind is code comments. These can be noisy and are not always relevant. I believe you should apply the same rules you apply to code design, in terms of separating your concerns, using Git for the documentation and the code for the code. These comments also have a tendency of becoming out of date.</p>
<p>Here are five principles we live by at FutureLearn when it comes to Git:</p>
<h2><b>1. Atomic commits</b></h2>
<p>Large commits can be difficult to read, especially when they contain changes which are unrelated. I&#8217;ll admit that it is often difficult to think about how you might split up a large commit, but I find it helps to think about the purpose of each commit.</p>
<p>Think of atomic commits as the smallest amount of code changed which delivers value &#8211; whether it’s tidying up existing code or introducing a new (small) feature.</p>
<pre>commit: [REDACTED]
Date:   [REDACTED]
   Allow educators to invite users onto courses.
61 files changed, 937 insertions(+), 81 deletions(-)</pre>
<p>With this example there are a lot of changes in this one commit. On the surface it might look like all these changes are related. However, if you were to break down the changes, you would have a better sense of what&#8217;s going on, for example:</p>
<pre>a6455f8 Record when enrolment is created via an invitation.
b529f6d Allow invited users to enrol on courses.
b5bb6e4 Allow invited users to see the course description page.
c829cbc Send enrolment invitation emails in batches of 1000.
5feaccf Allow educators to invite users onto courses.</pre>
<p>Now that this example has been split up, it starts to become more useful; not only is each commit smaller, it also gives you a better story of what has happened.</p>
<h2><b>2. Useful commit messages</b></h2>
<p>Writing commit messages can be difficult, but it helps to have a purpose in mind. We’re already breaking the changes down into atomic commits, meaning we should have a good idea of the value of each commit.</p>
<p>If there&#8217;s one thing to remember, it is to explain why you&#8217;ve made the change in the first place. This is the perfect opportunity to reflect on what you&#8217;re doing and to provide context &#8211; whether it&#8217;s to satisfy a user requirement, to fix a bug or to make another change easier to make in the future.</p>
<p>I find it helps to look at the commit from the perspective of another developer. What questions might they be asking when looking at your code changes? What might not be immediately obvious?</p>
<p>In terms of good practice, the following template is a good start. However, bear in mind that every commit is different.</p>
<pre>Short one line title.

An explanation of the problem, providing context (this may be as simple
as a reference to the user story).

Longer description of what the change does.

An explanation of why the change is being made.

Perhaps a discussion of alternatives that were considered.</pre>

<p>The first line should be used to explain the value of the changes, rather than focussing on the implementation details. By keeping this concise, we allow the reader to easily scan over the commit and find the code changes they are interested in.</p>
<p>The rest of the Git commit message depends on the change, but it’s always useful to explain what you’ve changed and why you’ve changed it.</p>
<p>I find it also helps in some cases, to provide further context such as explaining alternative solutions you&#8217;ve ruled out or providing external references.</p>
<pre>Correct the colour of FAQ link in course notice footer

PT: https://www.pivotaltracker.com/story/show/84753832

In some email clients the colour of the FAQ link in the course notice
footer was being displayed as blue instead of white. The examples given
in PT are all different versions of Outlook. Outlook won't implement
CSS changes that include `!important` inline [1].

Therefore, since we were using it to define the colour of that link,
Outlook wasn't applying that style and thus simply set its default
style(blue, like in most browsers).

Removing that `!important` should fix the problem.

[1] https://www.campaignmonitor.com/blog/post/3143/outlook-2007-and-
the-inline-important-declaration/</pre>

<p>This example has a clear headline, it outlines the problem, the developer’s intent and also provides context around the change.</p>
<h2><b>3. Revise history before sharing</b></h2>
<p>When developing your code, you are bound to change direction or even make mistakes (most commonly introducing typos or bugs).</p>
<pre>324d079 Fix typo in enrolment flash message
3a85f77 Only display enrol button for users who can enrol
4cc4778 Allow users to enrol on courses</pre>
<p>In this example, the developer has introduced a typo in their first commit, which they have fixed in a later commit.</p>
<p>Before you share your commit history, it&#8217;s important to think about what is useful information for someone else to read. You shouldn’t think of your Git history as a &#8220;truthful&#8221; log of what you worked on step-by-step. Just as we refactor code, we should refactor our commits before sharing them with others.</p>
<p>The power of Git makes it simple to re-order, reword and refactor your commits until they tell the clearest story possible.</p>
<p>Git’s interactive rebasing functionality allows us to tell a clearer story:</p>
<pre>$ git rebase --interactive

3a85f77 Only display enrol button for users who can enrol
773e345 Allow users to enrol on courses</pre>

<p>By reducing the amount of noise in your commit history, you can save you and your team time.</p>
<p>If you&#8217;re struggling with this process, I find that using Pull Requests is a great way to collaborate on shaping the commit history of your feature branch.</p>
<h2><b>4. Single purpose branches</b></h2>
<p>Long-living feature branches can often be difficult to keep up to date with master. I find that it is important to think about the purpose and scope of your feature branch.</p>
<p>Although you might be working on a single feature (user story), this doesn&#8217;t necessarily mean that you can&#8217;t deliver value in stages.</p>
<pre>5ce95fb Notify educators when an invitation has been accepted.
5ce95fb Refactor specs around enrolment invitations.
ee95245 Extend enrolment invitation to educators.
cfb2fb4 Tidy up whitespace in enrolment invitations spec.</pre>
<p>Like with this example, you may find that you are having to change/refactor key areas of the codebase in order to implement the feature you are developing. These changes can often provide a clear benefit that isn’t directly related to the feature branch, and can be landed on master separately (and earlier).</p>
<pre>$ git cherry-pick cfb2fb4 5ce95fb

* 0564508 Merge branch 'educator-enrolment-invitations'
  |\
  | _ 5ce95fb Notify educators when an invitation has been accepted.
  | _ ee95245 Extend enrolment invitation to educators.
  | |
  |/
* 5ce95fb Refactor specs around enrolment invitations.
* cfb2fb4 Tidy up whitespace in enrolment invitations spec.</pre>
  <p>By splitting up your feature branches, you not only reduce the pain of merging each branch, you also deliver value sooner and make your Git history more readable.</p>
    <h2><b>5. Keep your history linear</b></h2>
<p>Often, merging changes into master can result in your history becoming tangled and difficult to read.</p>
<pre>*   ce91a05 Merge branch 'reprint-statements'
|\
| * ae43ad0 Disable reprint link for refunded purchases.
| * 0b1abb0 Allow admins to flag purchases for re-printing.
* | 35d0357 Put dates formats in the pattern library
* | 275206c Merge branch 'fulfilment-attempt'
  |\ \
  | _ | 7aae45b Populate `fulfilled?` for existing purchases.
  | _ | 8e461b1 Display purchase fulfilment attempts to admins.
* | | 1adc0a9 Reduce padding around the course run date
  | |/
  |/|</pre>
  <p>This becomes even more of an issue when you have several feature branches being developed in parallel.</p>
    <pre>*   ce91a05 Merge branch 'reprint-statements'
|\
| * ae43ad0 Disable reprint link for refunded purchases.
| * 0b1abb0 Allow admins to flag purchases for re-printing.
|/
* 35d0357 Put dates formats in the pattern library
* 275206c Merge branch 'fulfilment-attempt'
  |\
  | _ 7aae45b Populate `fulfilled?` for existing purchases.
  | _ 8e461b1 Display purchase fulfilment attempts to admins.
  | \* 44cbfd0 Introduce Fulfilment attempts
  |/
* 1adc0a9 Reduce padding around the course run date</pre>
  <p>When it comes to merging, we try to preserve our merges commits and to rebase our feature branches before merging.</p>
    <pre>$ git checkout reprint-statements
$ git rebase master
$ git checkout master
$ git merge --no-ff reprint-statements</pre>
    <p>This allows us to group related commits together while keeping our merges clean, making it a lot easier to identify when a particular change was introduced.</p>
<p>We also find it often helps to commit smaller changes directly onto master.</p>
<h2><b>Summary</b></h2>
<p>If you spend as much time ensuring your commits are well factored as you do refactoring your code and tests, it will save you and your team time and pain in the future.</p>
<p><strong>How do you use Git? What sort of problems do you think it solves? Let us know in the comments below.</strong></p>
<p><strong>Want to know more about how we use Git? <a href="https://skillsmatter.com/skillscasts/6128-telling-stories-through-your-commits">Watch a talk from our CTO</a>, Joel Chippindale.</strong></p>
<p><strong>You might also find the following links useful: <a href="http://pcottle.github.io/learnGitBranching">LearnGitBranching</a>; <a href="http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html">A Note About Git Commit Messages</a>; <a href="http://think-like-a-git.net/">Think Like a Git</a>; and <a href="https://github.com/gazler/githug">GitHug</a>.</strong></p>