From a Whole Weekend to One Afternoon: Using AI to Reconstruct a Project's Evolution Timeline from Git History

First, a Failed Attempt

Last year I took over a legacy project that had been running for five years, with handover documentation amounting to half a page. The product manager asked me: "When was this coupon feature added? Why was it limited to one coupon per order at the time?" I opened the code—nothing in the comments, nothing in the docs. I asked three former colleagues who had already left, and got three contradictory answers.

So I decided to dig through the Git history myself. git log pulled out over eight thousand commits. I spent an entire weekend going through commit messages one by one, trying to arrange the feature evolution chronologically. The result? A timeline I couldn't even bear to look at myself: half the commit messages were "fix bug," "update," or "temporary fix," and the other half were a mess of mixed Chinese and English. My manually compiled timeline had an extremely high error rate—I misjudged refactors as new features, treated experimental code as official releases, and completely missed an important branch that had been reverted.

There are several other common failure patterns you've probably seen too:

Failure pattern one: dumping tens of thousands of lines of logs into AI without any rules. The AI produces a seemingly fluent "evolution epic" with mismatched dates and features conjured out of thin air. It looks beautiful, but it's all made up.

Failure pattern two: only looking at commit messages, not code diffs. Commit messages are subjective human descriptions; diffs are objective facts. A commit labeled "optimize login" might hide an entirely new registration flow in its diff.

Failure pattern three: asking AI to summarize three years of history in one go. The context gets stuffed to capacity, the model can only skim, and large "amnesia" gaps appear in the middle of the timeline—exactly missing the quarter you care about most.

I've fallen into all three of these traps. Here's the correct path I figured out afterward.

The Correct Path: Divide and Conquer, Let Evidence Speak

The core idea in three sentences: slice by time, gather evidence from diffs, and let AI only summarize—never guess.

Step 1: Clean and Slice

First, use git commands to turn the raw log into structured data, slice it by quarter or milestone, and feed AI only one segment at a time:

git log --pretty=format:"%h|%ad|%an|%s" --date=short > git_log.txt

A five-year project becomes a dozen or so segments, each with a few hundred commits—enough for AI to read completely and accurately.

Step 2: Give AI "Evidence," Not "Freedom"

For key nodes (major releases, suspicious commits), include the diff summary as well:

git show <commit> --stat

Let AI see both "what people said" and "what the code did." Cross-referencing the two dramatically reduces hallucination.

Step 3: Constrain the Output with a Prompt Template

This is the most critical part of the entire process. Here's the template I use—feel free to copy and adapt it:

你是一名熟悉 Git 工作流的代码考古助手。我会提供一段项目的 Git 提交记录（可能附带部分 diff 摘要），请帮我梳理这段时期的功能演进时间线。

规则：
1. 只基于我提供的提交记录和 diff 摘要推断，禁止推测未提及的功能或动机；
2. 区分四类变更：新功能、功能增强、重构、缺陷修复，不确定的归入"待确认"；
3. 将零散提交聚合为"功能事件"，每个事件标注：起止时间、涉及的核心提交哈希、演进脉络（如何从首个提交走到最终形态）；
4. 提交信息含糊时（如"fix bug""修改"），结合 diff 摘要判断真实意图；无法判断则明确标注"信息不足"，不要编造；
5. 输出末尾附"疑点清单"：可疑的时间断层、被 revert 的提交、语义矛盾的提交信息。

输出格式：按时间排序的事件列表 + 疑点清单。

以下是提交记录：
{粘贴 git_log 片段}

以下是关键提交的 diff 摘要（可选）：
{粘贴 git show --stat 输出}

Step 4: Follow Up and Verify

After the first round of output, drill into the list of suspicious items: "Commits a1b2c3 and d4e5f6 are two months apart but modify the same module—what happened in between?" Use git log -- path/to/module to gather additional evidence and ask another round. Usually after two rounds, the timeline is solid enough.

Before and After: One Weekend vs. One Afternoon

The most valuable part is actually that "list of suspicious items." When working manually, I thought I hadn't found any problems; among the suspicious items AI flagged, two were later confirmed to be traces of a rollback from a production incident years ago—information even the product manager didn't know about.

A Few Reminders

1. Model selection: Parsing long logs demands both context length and instruction-following capability. I recommend using a unified gateway for model switching and comparison—one trial run will tell you which model summarizes your codebase most accurately. For pricing, refer to the official pricing page.
2. Don't skip the cleaning step: Pasting the entire raw git log output is just stepping back into all three traps.
3. Have humans review the timeline: Spend ten minutes manually verifying the items AI flagged as "to be confirmed," and the timeline goes from "mostly reliable" to "ready for the handover docs."
4. Solo developers can benefit too: Even if you're the only one on the project, six months later you'll forget "how the permission system ended up looking like this." Run the process after each major release, and you get an automatically generated project chronicle.

Final Thoughts

The hard part of code archaeology isn't the organizing—it's the unreliability of memory and the fragmentation of information. AI can't change history, but it can piece together the evidence scattered across eight thousand commits into an evolution timeline you'd dare bring to a meeting, all within one afternoon.

If you haven't tried using AI for repository-level work yet, start by tracing your own project's Git history. The barrier to entry is low, results come fast, and you get to test how different models actually perform on long-text summarization. If you want to switch between and compare multiple models within the same workflow, you can first register a unified gateway account at https://api.thistoken.ai/register to minimize the cost of model selection.

---

Tired of juggling provider integrations? Register at https://api.thistoken.ai/register and call every model through one base_url.