Re: How to generate feature branch statistics?

From: Jeff King <peff@peff.net>
Date: Jul 20, 2016, 13:14 UTC
Message-ID: <20160720131424.GC17469@sigill.intra.peff.net>
In-Reply-To: <CAOHAwykGkfY7M30jT8t0k6Gsdy5QSBHmAPiWYoKibjUgS-G6hg@mail.gmail.com>

On Wed, Jul 20, 2016 at 10:05:09AM +0200, Ernesto Maserati wrote:

Show 9 quoted lines

> I assume that feature branches are not frequently enough merged into
> master. Because of that we discover bugs later than we could with a more
> continuous code integration. I don't want to discuss here whether feature
> branches are good or bad.
> 
> I want just to ask is there a way how to generate a statistic for the
> average duration of feature branches until they are merged to the master? I
> would like to know if it is 1 day, 2 days or lets say 8 or 17 days. Also it
> would be interesting to see the statistical outliers.

In a workflow that merges feature branches to master, you can generally recognize them by looking for merges along the first-parent chain of commits:

  git log --first-parent --merges master

(Depending on your workflow, some feature branches may be fast-forwards with no merge commit, so this is just a sampling. Some workflows use "git merge --no-ff" to merge in feature branches, so this would see all of them).

And then for each merge, you can get the set of commits that were merged in (it is the commits in the second parent that are not in the first). The bottom-most one is the "start" of the branch (or close to it; of course the author started writing code before they made a commit), and the "end" is the merge itself.

So something like:

  git rev-list --first-parent --merges master |
  while read merge; do
	start=$(git log --format=%at $merge^1..$merge^2 | tail -1)
	end=$(git log -1 --format=%at $merge)
	subject=$(git log -1 --format=%s $merge)
	echo "$((end - start)) $subject"
  done

That should output a sequence of topic branch merges prefixed by the number of seconds they were active. Two exercises for the reader:

  1. Converting seconds into some more useful time scale. :)

  2. This can probably be done with fewer invocations of git,
     which would be more efficient.

-Peff