開発者のコ​​ミット統計はなぜ有害なのですか？

私は長い間、各開発者が1日に行うコミットの数などのコミット統計を追跡することは、開発プロセスに有害であると信じてきました（そして他の人からも聞いた）。その理由は明らかです-開発者はより小さな増分でコミットし、1日あたりのコミット数を最大化しますが、二分することを難しくします（おそらく、すべての中間パッチはリポジトリを適切な形式にしないため）、コミット履歴を操作するのが難しくなります。 （変更は突然ではなく、複数のコミットで行われます。1つではなく、パッチを元に戻すのが難しくなります）。

コミット統計が有害であることを示す研究はありますか？このトピックに関するエレガントで議論の多い記事はありますか？同様に当てはまるのは、間違ったものを測定すると人々が間違ったものを最適化することにつながり、この問題は単なる特殊なケースです。

http://www.mit.edu/~hauser/Papers/Hauser-Katz%20Measure%2004-98.pdf

これはあなたが探しているものですか？Googleが見つけた何千もの「測定したものだけを取得する」記事があります。

測定するのは楽しい統計ですが、開発者が1週間に費やした時間数を記録することほど役に立ちません。

まず、コードの品質は考慮されていません。ある開発者は、コードのバグを修正し続けているため、継続的にコミットしている可能性があります。これは、完成した洗練されたコードの1つのチャンクをコミットする開発者と比較して、多数のコミットを示します。コミット数が多い人ほど優れた開発者であるとは思わないでしょう。

同様に、1日1回だけコミットするために1日中緩やかにSOをサーフィンする人は、コードの安全を保つために終日の最終コミットのみを行うために終日コーディングに費やした熱心な開発者と同じコミット数になります。

コミットされたコードの行が数えられるシステムを持っている場合、自分の好みのスタイルにすべての中かっこを「リファクタリング」してソースファイルを調べる人は、大きな価値を持つことになります。1行の非常に重要なバグ修正を行った人はほとんど現れません。

したがって、開発者がシステムをゲームしなくても、意味のある統計は作成されません。きれいなグラフ以外は何もないはずです。しかし、誰もが統計を好むので、私はそれらを保持すると言いますが、楽しみ以外には何も使用しないでください。