Good ways to manage a changelog using git?

Question

Hello all,

I've been using Git for a while now, and I recently started using it to tag my releases so that I could more easily keep track of changes and be able to see which version each of our clients are running (unfortunately the code currently mandates that each client have their own copy of the PHP site; I'm changing this, but it's slow-going).

In any case, we're starting to build some momentum, I thought it would be really good to be able to show people what has changed since the last release. Problem is, I haven't been maintaining a changelog because I don't have a good idea of how to go about it. For this particular time, I can run through the log and manually create one, but that will get tiring very quickly.

I tried googling "git changelog" and "git manage changelog" but I didn't find anything that really talked about the workflow of code changes and how that coincides with the changelog. We're currently following Rein Henrichs' development workflow and I would love something that went along with that.

Is there a standard approach that I am missing, or is this an area where everybody does their own thing?

Thanks very much for your comments/answers!

Answer 1

You can use some flavor of git log to help you out:

git log --pretty=%s                 # only print the subject

If you name your branches nicely, so that a merge to master shows up as something like "Merged branch feature-foobar", you can shorten things by only showing that message, and not all the little commits that you merged, which together form the feature:

git log --pretty=%s --first-parent  # only follow first parent of merges

You might be able to augment this with a script of your own, which could do things like strip out the "Merged branch" bits, normalize formatting, etc. At some point you have to write it yourself though, of course.

Then you could create a new section for the changelog once per version:

git log [opts] vX.X.X..vX.X.Y | helper-script > changelogs/X.X.Y

and commit that in your version release commit.

If your problem is that those commit subjects aren't anything like what you'd want to put in a changelog, you pretty much have two options: keep doing everything manually (and try to keep up with it more regularly instead of playing catch-up at release time), or fix up your commit message style. One option, if the subjects aren't going to do it for you, would be to place lines like "change: added feature foobar" in the bodies of your commit messages, so that later you could do something like git log --pretty=%B | grep ^change: to grab only those super-important bits of the messages.

I'm not entirely sure how much more than that git could really help you create your changelogs. Maybe I've misinterpreted what you mean by "manage"?