I Was Tired of Writing Commits Like “final_final_v7_ACTUAL_FINAL”

我厌倦了写出像“最终_最终_v7_真的最终版”这样的提交信息

Let’s be honest for a second. GitHub contribution graphs are not a productivity metric. They are not a measure of skill. They are not a measure of impact. They are not a measure of how much suffering you endured debugging something that turned out to be a missing semicolon. They are a vibe metric. And yet — every developer has stared at their graph and felt a quiet, irrational pang of guilt: Damn. I swear I worked more than that. 坦白说，GitHub 的贡献图表并不是生产力指标。它不能衡量技术水平，不能衡量影响力，也不能衡量你在调试一个仅仅因为少写了分号的 Bug 时经历了多少痛苦。它只是一个“氛围指标”。然而，每个开发者都曾盯着自己的图表，感到一阵莫名的愧疚：“该死，我明明工作得比这多得多。”

That feeling is exactly why I built my latest project: an Auto Commit Desktop App. Not to cheat the system. Not to farm fake internet points. Mostly out of curiosity. And partly because my GitHub graph looked like it had clinical depression. 这种感觉正是促使我开发最新项目的原因：一个自动提交桌面应用。我不是为了作弊，也不是为了刷虚荣的互联网积分，主要是出于好奇，也因为我的 GitHub 图表看起来像是患上了临床抑郁症。

The Problem (Which Was Entirely My Own Fault) I have a bad habit. Actually, several. But this post is only about one of them. I write code — sometimes a lot of it — and then tell myself: I’ll commit it later. Historically, every catastrophic decision begins with those four words. Hours pass. Sometimes days. Then I finally push everything in one massive, guilt-ridden commit: git commit -m “final final FINAL fixed version 7 actually working” 问题所在（完全是我自己的错）：我有一个坏习惯。其实有好几个，但这篇文章只谈其中一个。我写代码——有时写很多——然后告诉自己：等会儿再提交。历史上，每一个灾难性的决定都始于这四个字。几小时过去了，有时甚至几天。最后，我把所有东西一股脑儿地塞进一个巨大的、充满负罪感的提交中：git commit -m "最终最终最终修复版7真的能用了"。

Which tells future-me absolutely nothing. Future-me opens the repository, sees 1,284 files changed, and quietly questions every life choice that led to this moment. The real damage isn’t the messy graph. It’s that a commit history like that is completely unreadable. You lose context, you lose causality, and you lose the ability to understand why something changed — which is, arguably, the entire point of version control. 这对于未来的我来说毫无意义。未来的我打开仓库，看到 1,284 个文件被修改，默默地质疑导致这一刻的所有人生选择。真正的损害不在于混乱的图表，而在于这样的提交历史完全无法阅读。你失去了上下文，失去了因果关系，也失去了理解代码为何变更的能力——而这，可以说正是版本控制的全部意义所在。

The Funny Thing About Developer Consistency Developers love consistency. We automate everything. We write scripts to save five seconds. We create shell aliases because typing six extra characters feels like a personal insult. And yet — we still forget to commit. I found that genuinely funny. My editor remembers every setting. My browser remembers passwords I’ve forgotten myself. My operating system still knows the WiFi password for an apartment I moved out of two years ago. But Git? Git just waits. Patiently. Indefinitely. Without judgment. And I never remember. 关于开发者一致性的趣事：开发者热爱一致性。我们自动化一切。我们写脚本只为了节省五秒钟。我们创建 Shell 别名，因为多打六个字符感觉就像是对个人的侮辱。然而，我们还是会忘记提交。我觉得这真的很有趣。我的编辑器记得每一个设置，浏览器记得连我自己都忘了的密码，操作系统甚至还记得我两年前搬离的公寓的 WiFi 密码。但 Git 呢？Git 只是在等待。耐心地，无限期地，不加评判地。而我却总是记不住。

So I Built the App The original idea was stupidly simple: a desktop app that prompts or schedules commits automatically. Set it, forget it, stay consistent. Then scope happened. Because every side project starts with “this should take a weekend” and ends three weeks later with you reading Electron documentation at 2 AM, wondering where things went wrong. 于是我开发了这个应用。最初的想法简单得愚蠢：一个自动提示或定时提交的桌面应用。设置好，不用管，保持一致性。然后，项目范围就开始膨胀了。因为每个副业项目都始于“这周末就能搞定”，却终于三周后你凌晨两点还在读 Electron 文档，纳闷事情到底哪里出了错。

Suddenly I was building: Commit scheduling with configurable intervals, a preview system so you can review changes before they’re committed, rollback functionality for when automation does something dumb, safety checks to prevent committing broken or half-finished states, commit message pattern generation, repository validation to avoid running on the wrong directory. The project became significantly more complicated than the problem that inspired it. Which is, of course, the most developer thing ever. 突然间，我开始开发：可配置间隔的提交调度、提交前的变更预览系统、自动化出错时的回滚功能、防止提交损坏或未完成状态的安全检查、提交信息模板生成、以及防止在错误目录运行的仓库验证。这个项目变得比它试图解决的问题复杂得多。当然，这非常“开发者”。

The Unexpected Rabbit Hole Building the app forced me to sit with a question I’d never seriously asked before: Why do developers care so much about contribution graphs? Think about it. If one developer ships a meaningful feature over the course of a quiet week, and another makes 47 tiny commits tweaking whitespace and updating README punctuation — who contributed more? The graph gives the second developer a greener week. The graph measures activity, not value. Not depth of thinking, not quality of decisions, not the hours spent reading documentation trying to understand why something works at all. Just: did a commit happen today? Yes or no. That’s a pretty thin signal to be emotionally invested in. And yet, here we are. 意想不到的深坑：开发这个应用迫使我面对一个从未认真思考过的问题：为什么开发者如此在意贡献图表？想一想，如果一个开发者在安静的一周内发布了一个有意义的功能，而另一个开发者进行了 47 次微小的提交，只是调整了空格和更新了 README 的标点符号——谁贡献更多？图表会让第二个开发者的那一周看起来更“绿”。图表衡量的是活跃度，而不是价值。它衡量不了思考的深度、决策的质量，也衡量不了为了理解代码原理而阅读文档所花费的时间。它只衡量：今天提交了吗？是或否。为了这样一个单薄的信号投入情感，实在不值。然而，我们却深陷其中。

The Real Lesson: Goodhart’s Law, But Make It Developer-Flavored There’s a principle called Goodhart’s Law: “When a measure becomes a target, it ceases to be a good measure.” We’ve watched this play out everywhere: GitHub contributions were originally a simple visualization — a way to see at a glance whether a repository was active. Somewhere along the way, developers started treating it like a performance review. Those are very different things. And the moment we started optimizing for the graph, we stopped being honest with ourselves about what the graph actually shows. 真正的教训：古德哈特定律（Goodhart’s Law）的开发者版本。有一条原则叫古德哈特定律：“当一个指标变成目标时，它就不再是一个好指标了。”我们随处可见：GitHub 贡献图最初只是一个简单的可视化工具，让人一眼就能看出仓库是否活跃。不知从何时起，开发者开始把它当作绩效考核。这两者截然不同。当我们开始为了图表而优化时，我们就不再诚实地面对图表真正展示的内容了。

Ironically, the App Made Me Commit More Not because it automated my commits. Because building it made me pay attention to my own workflow in a way I never had before. I started noticing: How often I delayed commits not from laziness, but from vague perfectionism — waiting until the code felt “ready enough” to be recorded; How often I used version control as a backup system rather than a decision log; How often my commit messages were instructions to future-me (“fix this later”) instead of explanations from past-me (“here’s what I learned”). The app solved a technical problem. But it exposed a human one. 讽刺的是，这个应用反而让我提交得更多了。不是因为它自动化了提交，而是因为开发它的过程让我以前所未有的方式关注自己的工作流。我开始注意到：我经常推迟提交不是因为懒，而是因为模糊的完美主义——总想等到代码“足够好”才记录；我经常把版本控制当作备份系统，而不是决策日志；我的提交信息经常是给未来的我的指令（“稍后修复”），而不是过去的我留下的解释（“这是我学到的东西”）。这个应用解决了一个技术问题，却暴露了一个人性问题。

What Developers Actually Forget We think we forget to commit. We don’t. We forget discipline. We forget that version control isn’t a formality — it’s a way of narrating the evolution of a project. The best commit histories I’ve read almost function like a development journal. You can trace not just what changed, but why, and occasionally even what didn’t work before this. That’s genuinely valuable — for teammates, for future contributors, and especially for yourself six months later. A good commit history tells a story. A bad commit history looks like a crime scene. Mine usually looked like a crime scene. 开发者真正忘记的是什么？我们以为自己忘了提交，其实不是。我们忘记的是纪律。我们忘记了版本控制不是一种形式，而是叙述项目演变的一种方式。我读过最好的提交历史几乎就像开发日志。你不仅能追踪到什么变了，还能知道为什么变，甚至偶尔能看到在此之前什么方法行不通。这非常有价值——对队友、对未来的贡献者，尤其是对六个月后的你自己。好的提交历史在讲故事，坏的提交历史看起来像犯罪现场。而我的通常看起来像犯罪现场。

The Question Nobody Wants to Answer Honestly If GitHub removed contribution graphs tomorrow — would you code any differently? Would you commit differently? Would you structure your work differently? 没人愿意诚实回答的问题：如果明天 GitHub 删除了贡献图表，你的编码方式会改变吗？你的提交方式会改变吗？你的工作结构会改变吗？