GitHubの芝（Contribution Graph）は自由に操れるのか？過去日付コミットの検証

2025-11-22
TechGitHub

はじめに

エンジニアの皆さん、GitHubの「芝」（Contribution Graph）、生やしていますか？
日々の活動の証として緑色が濃くなっていくのを見るのはモチベーションに繋がりますよね。

しかし、このContribution Graphは、実はGitの仕組み上、過去の日付でコミットを作成することで、後から自由に「生やす」ことが可能です。
今回は、Gitの仕様を理解するために、実際に過去日付のコミット（Backdated commits）を作成し、GitHubのContribution Graphがどのように変化するか（理論上どうなるか）を検証してみました。

注意: 本記事はGitの仕様理解を目的とした技術検証の記録です。
虚偽の活動履歴を作成して他者を欺く行為や、チーム開発のリポジトリでの実行は推奨されません。(あくまで個人の実験用リポジトリで試しています)

検証の仕組み

Gitのコミットには、主に2つのタイムスタンプが含まれています。

  1. Author Date: コードを書いた日時
  2. Committer Date: コミットを適用した日時

GitHubのContribution Graphは、このうち Author Date を参照して描画されます。
つまり、コミットを行う際に環境変数を操作して Author Date を過去の日付に設定すれば、その日の活動として記録されるわけです。

コマンドラインでは以下のように環境変数を指定することで実現できます。

GIT_AUTHOR_DATE="2024-09-01T12:00:00" \
GIT_COMMITTER_DATE="2024-09-01T12:00:00" \
git commit -m "Backdated commit"

検証内容

今回は、以下の条件で大量の過去日付コミットを生成するスクリプトを作成し、検証を行いました。

  • 期間: 2024年12月1日 〜 2025年9月30日
  • 回数: ランダムに500回
  • 手法: Pythonスクリプトでランダムな日時を生成し、シェルスクリプトで git commit をループ実行

使用したスクリプト（抜粋）

#!/bin/bash

# Pythonを使ってランダムな日付を生成
dates=$(python3 -c '
import random
from datetime import datetime, timedelta

start = datetime(2024, 12, 1)
end = datetime(2025, 9, 30, 23, 59, 59)
delta = (end - start).total_seconds()
count = 500

dates = []
for _ in range(count):
    sec = random.randint(0, int(delta))
    d = start + timedelta(seconds=sec)
    dates.append(d.isoformat())

dates.sort()
print("\n".join(dates))
')

# 生成された日付ごとにコミットを作成
for d in $dates; do
  echo "$d log" >> log.txt
  git add log.txt
  GIT_AUTHOR_DATE="$d" GIT_COMMITTER_DATE="$d" git commit -m "Backdated commit for $d"
done

結果

スクリプトを実行すると、ローカルリポジトリには指定した期間にわたる膨大なコミットログが生成されました。
git log で確認すると、確かに Author Date が指定した過去の日付になっています。

これをpushしたところ、GitHub上のプロフィールページには、実際には活動していない日のマス目が緑色に埋め尽くされました。(量が多いためgithubへの反映までに数分かかりました)

代替テキスト

まとめと考察

今回の検証で、Gitのコミット履歴はあくまで「自己申告」のタイムスタンプに基づいていることが再確認できました。 これはGitが分散型バージョン管理システムであり、オフラインでの作業やパッチの適用などを柔軟に行うための仕様ですが、同時に「活動履歴の改竄」も容易であることを意味します。

エンジニアの採用面接などで「GitHubの芝」が話題になることもありますが、芝の量だけでスキルや活動量を単純に判断するのは危険かもしれません。コミットの中身や質、コードレビューのやり取りなど、より本質的な部分を見る必要がありますね。

技術的な好奇心として「過去に芝を生やす」実験は面白いですが、実際の運用では正直な履歴を積み重ねていきましょう！