Gitは単なる履歴帳ではない：`git-log`と`jq`で抽出する「開発チームの真実」
多くのエンジニアが`git log`を眺めて終わっている。しかし、真のDevOpsエンジニアにとって、Gitリポジトリは「プロジェクトの全活動が記録された巨大な時系列データベース」だ。
今回は、GUIツールが隠蔽してしまう「開発の鼓動」を、CLIの極限パイプラインで可視化するテクニックを伝授する。
—
1. GitをJSONデータベースとして召喚する
`git log`の出力を加工する際、文字列パースで苦しむのは今日で終わりにしよう。`–pretty=format`を使い、直接JSONとして流し込むのがプロの流儀だ。
現場で使う最強のgit log抽出コマンド
git log –pretty=format:'{“hash”:”%h”,”author”:”%an”,”date”:”%ad”,”subject”:”%s”,”files”:%>(10,trunc)%n}’ –date=iso-strict
これを`jq`に渡せば、複雑な分析も数秒で終わる。まずは、開発者のコミット頻度を抽出する基本形を叩き込んでほしい。
—
2. 実践：チームの活動を可視化するパイプライン
A. 開発者の貢献度ランキング（コミット数ベース）
単純な行数よりも「どれだけ頻繁にコンテキストを切り替えて成果を出しているか」を見る指標だ。
git log –pretty=format:'{“author”:”%an”}’ | \
jq -s ‘group_by(.author) | map({author: .[0].author, count: length}) | sort_by(.count) | reverse’
B. 時間帯別アクティビティ（バーンアウトの予兆検知）
深夜のコミットが急増していないか？このスクリプトで「チームの健康状態」を定量化できる。
git log –pretty=format:'{“time”:”%ad”}’ –date=format:’%H’ | \
jq -s ‘group_by(.time) | map({hour: .[0].time, count: length}) | sort_by(.hour)’
—
3. 生産性を加速させる「隠れた設定」とベストプラクティス
コマンドだけでは足りない。環境を研ぎ澄ませ。
① Gitエイリアスの極致
`.gitconfig`に以下を追記せよ。これは単なる短縮ではなく、思考を中断させないためのスイッチだ。
[alias]
# 変更分をJSONとして即座に抽出するカスタムコマンド
json-log = !git log –pretty=format:'{“hash”:”%h”,”author”:”%an”,”date”:”%ad”,”msg”:”%s”}’
# マージ済みブランチを掃除する（事故防止のためdry-runを推奨）
cleanup = “!git branch –merged | grep -v ” | xargs git branch -d”
② チームで共有すべき「神設定」
プロジェクトルートに `.gitconfig.local` を置き、CI/CD用やプロジェクト専用の設定を分離せよ。特に`core.hooksPath`をリポジトリ直下の`githooks`ディレクトリに向けることで、チーム全員に強制的にlintを走らせる体制を作れる。
プロジェクト特有のフック設定
git config core.hooksPath .githooks
—
4. 現場で震えるほど役立つ「可視化」のハック
チーム開発において、最も重要なのは「誰が何を作ったか」ではなく、「どのファイルがボトルネックになっているか」を特定することだ。
以下のワンライナーは、修正頻度が高いファイルトップ10を抽出する。これに該当するファイルは、リファクタリングの最優先候補である。
git log –name-only –pretty=format: | \
grep -v ‘^$’ | \
sort | uniq -c | sort -nr | head -n 10
テックリードからのアドバイス：
もし、このリストのトップに「複雑なビジネスロジック」や「巨大なコンフィグファイル」が入っているなら、それは技術的負債が溜まっている証拠だ。マネジメント層へ「このファイルを分割・リファクタリングするために、今週のチケットの20%を割くべきだ」と、定量的根拠を持って交渉せよ。 これが、エンジニアリングで組織を動かす力だ。
—
5. 最後に：ツールに使われるな、ツールを使い倒せ
CI/CDスペシャリストとして断言する。ツールは「目的」ではない。チームの心理的安全性を高め、開発の無駄を削ぎ落とし、リリースまでのリードタイムを最短にするための「手段」に過ぎない。
Gitの履歴をJSONとして扱うことは、単なる集計遊びではない。それは、自分の書いたコード、チームが積み上げた苦労を「客観的な事実」として直視する行為だ。
さあ、ターミナルを開け。今すぐ君のリポジトリから「真実」を抽出してみろ。そこには、君のチームが次に進むべき道が、確実に記されているはずだ。