1. 26
  1.  

  2. 2

    How about the best of both worlds: Keep your changelog-worthy items in the title of your commits and dump those automatically?

    Edit: I suppose rather than always forcing yourself into giant commits that are changelog-worthy, you could also do the above with a “Changelog:” preface in the title for such items.

    1. 8

      IMO this is the easiest way to implement this sort of thing. When I was working at Calxeda (small team, ~15 full time devs and me) the convention was that all commits on master had to fit the pattern

      [<jira ticket>] <short fix message>\n\n<long fix message>.

      You could do whatever you wanted off on your own working coppies, but when you had something ready to go squash it all down to one patch, write a changelog worthy commit and rebase it onto master. That meant we could just do a git log dump for customers because it was in fact meaningful.

      I think the real issue with keeping changelogs is that it requires issue tracker support and there isn’t a convention (besides GH, which isn’t exactly a well defined or open convention) for working with issues and change items from git.

    2. 1

      Heh ! I had come up with a similar convention.

      I would suggest one more entry to the list – Migrations.

      1. 1

        The discussion on HN : https://news.ycombinator.com/item?id=9054627

        TL;DR : “There is a standard change log format” and http://xkcd.com/927/