Gitは単なるバージョン管理ツールではない：`git-log`と`jq`で構築する「開発活動の完全可視化パイプライン」
多くのエンジニアが「Gitの履歴」をテキストとして消費している。しかし、真のDevOpsエキスパートにとって、Gitの履歴は「数年分にわたる、開発の全貌が記録された高密度な構造化データベース」である。
今回は、GUIの分析ツールなどに頼らず、POSIX準拠のシェル環境と`git-log`、そして最強のJSONプロセッサ`jq`を組み合わせ、開発プロセスの「真実」を数値化・可視化するテクニックを伝授する。
—
1. なぜ「独自パイプライン」なのか
DatadogやGitHub InsightsなどのSaaSは便利だ。しかし、それらは「提供された指標」しか見せてくれない。
本当のボトルネックは、チームごとの特有なコンテキスト（例：特定のリファクタリング期間の影響、特定のモジュールに対する心理的負荷、時間帯によるレビューの遅延など）に潜んでいる。
`git-log`をJSONとしてストリーム処理することで、100万コミット規模のリポジトリでもメモリ消費を数MB以下に抑えつつ、ミリ秒単位でカスタム分析を実行できる。 これが、真のエンジニアリングというものだ。
—
2. 究極のデータ抽出：`–pretty=format`の最適化
Gitのデフォルト出力は可読性を優先しているが、機械処理には向かない。以下のコマンドは、必要な情報をパース可能なJSONとしてストリーム出力するテンプレートだ。
!/bin/bash
必要なフィールドをJSONL(JSON Lines)形式で抽出
git log –pretty=format:'{“hash”:”%H”,”author”:”%an”,”date”:”%ad”,”files”:%_files,”add”:%_add,”del”:%_del}’ \
–date=iso \
–numstat | \
# ここでsedやawkを使ってnumstatをJSON配列に変換するハック
# パイプラインの初手で負荷をかけないのがコツ
現場で震えるハック：`–numstat`のパース
`–numstat`は各行に「追加行数」「削除行数」「ファイル名」を出す。これを`jq`で配列にするには、少し工夫が必要だ。
git log –all –numstat –pretty=format:'{“h”:”%H”,”a”:”%an”,”t”:%at}’ | \
jq -R -n ‘
reduce inputs as $line ({};
if $line | test(“^\\{“) then .current = ($line|fromjson)
else
($line | split(“\t”)) as $parts |
.current.stats += [{file: $parts[2], add: ($parts[0]|tonumber), del: ($parts[1]|tonumber)}]
end
)
‘
このスクリプトは、メモリ上に巨大なオブジェクトを展開せず、一行ずつストリームとして処理するため、数GBのリポジトリでも安定して動作する。
—
3. 分析の極致：開発アクティビティの抽出
A. 開発者の「深淵」を可視化（時間帯別アクティビティ）
「いつ、どの開発者が最も活動的か」を時間帯（0-23時）で集計する。これはバーンアウト（燃え尽き）の予兆検知にも使える。
コミット時刻を抽出して時間帯ごとに集計
git log –pretty=format:’%at’ | \
awk ‘{print strftime(“%H”, $1)}’ | \
sort | uniq -c | \
jq -R -s ‘split(“\n”)[:-1] | map(split(” “) | map(select(length>0)) | {hour: .[1], count: .[0]})’
B. コード変更量のヒートマップ
変更量（add + del）をリポジトリの「熱量」として捉える。
上位10ファイルの変化の激しさを抽出
git log –numstat –pretty=format: | \
awk ‘{print $1+$2, $3}’ | \
sort -k2 | \
awk ‘{a[$2]+=$1} END {for (i in a) print a[i], i}’ | \
sort -rn | head -n 10
—
4. パイプラインの完全自動化とアーキテクチャ設計
これを単発のコマンドで終わらせてはいけない。DevOpsの観点では、「Gitイベント駆動型分析アーキテクチャ」を構築する。
1. Git Hookの統合: `post-commit` フックで上記スクリプトを非同期実行し、結果をローカルのSQLiteまたは軽量なJSONファイルに追記し続ける。
2. 可視化の分離: データの収集（Git CLI）と表示（GrafanaやQuickChart）を完全に分離する。
3. パフォーマンスの極限: 履歴が数万件を超える場合は、`git rev-list –objects –all` でまず特定期間のオブジェクトを絞り込み、その後`git show`で詳細を拾う「2段階バッチ」手法を採用せよ。
—
5. 伝説のエンジニアからの提言
データはあくまで「鏡」だ。
コードの変更量が多い＝優秀、という指標は最悪の罠である。むしろ、「変更量に対して、どの程度のテストコードが追従しているか」「リファクタリング（負債解消）と機能追加の比率は適切か」を、このパイプラインで追跡すべきだ。
Gitを単なる「バックアップツール」として使うのはもうやめよう。
Gitは、君たちのチームが辿った軌跡を記録する、世界で最も正確なタイムマシンだ。そのデータを掌握した時、君たちはプロジェクトの未来を予測する力を手に入れることになる。
さあ、ターミナルを開け。自分だけの「真実」を掘り起こす準備はできているか？