Re: How to generate feature branch statistics?

[Jeff King <peff@peff.net>]

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

> 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