编程与软件工程chris.beams.io编辑精选
如何写好 Git 提交信息（2014）
How to Write a Git Commit Message (2014)
2015 — 2017，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
Chris Beams 的经典文章，讲解如何写好 Git 提交信息：提出了七条规则，核心是标题用祈使句、50 字符以内、首字母大写、不加句号等，并解释了好的提交信息对团队协作和历史追溯的价值。
为什么经久不衰：提交信息规范是每个开发者日常都会面对的问题，这篇文章给出了简洁、可操作的规则，多年来被广泛引用。
HN 评论精选
分享了一套以动词开头的团队提交信息约定
我的团队使用一套提交信息约定，便于快速阅读也能被工具链解析。我们约定了一小批开头的主动动词：Add（新增能力，如功能、测试、依赖）、Cut（移除能力）、Fix（修复问题，如 bug、笔误）、Bump（提升某物版本，如依赖）、Make（改动构建流程、工具或基础设施）、Start（开始做某事，如创建功能开关）、Stop（结束做某事，如移除功能开关）、Refactor（纯重构）、Reformat（格式化重构）、Optimize（性能重构）、Document（文档重构）。
jph查看英文原文
My team uses a git commit message convention that helps us read fast and also is parsable by toolchains. We agree on a short list of leading active verbs: Add = Create a capability e.g. feature, test, dependency. Cut = Remove a capability e.g. feature, test, dependency. Fix = Fix an issue e.g. bug, typo, accident, misstatement. Bump = Increase the version of something e.g. dependency. Make = Change the build process, or tooling, or infra. Start = Begin doing something; e.g. create a feature flag. Stop = End doing something; e.g. remove a feature flag. Refactor = A code change that MUST be just a refactoring. Reformat = Refactor of formatting, e.g. omit whitespace. Optimize = Refactor of performance, e.g. speed up code. Document = Refactor of documentation, e.g. help files.
提交规范应取决于团队想让 git 历史承担什么功能，而非套用普适规则
这类文章太多了，都在讲提交信息的规范性规则，但大家的结论总略有不同。真正该先讨论的是：你希望未来给开发者提供哪些工具？把 git 历史当作一等调试工具很强大，但并非必须，且每种工具都有成本。想要 bisect 可用？那多数提交就应是功能完整的版本，合并时可考虑 squash。想要记录奇怪决策的叙述性文档？细粒度提交是好去处，但可能让开发者不再写行内注释。想要通过 git blame 明确归属？逐行改动有帮助，但可能阻碍代码所有权的转移。我更愿意把 git 历史当作一种上下文工具，像监控、单元测试或文档一样，应该和团队坐下来定义你想用它做什么，再由此确定提交风格。
trjordan查看英文原文
There are so many articles like this, and all of them focus so much on prescriptive rules for commit messages. There's a similar set of articles on how to deal with branching and merging. Somehow, everybody comes to slightly different conclusions. The discussion that needs to happen before this is to understand what tools you want to make available to your developers in the future. Using git's history as a first class debugging tool is powerful, but it's by no means mandatory to provide. There's also a real cost to providing each of the tools. - Do you want bisect to be available? Well, then you should have most commits represent a fully-functional version of the software. Consider squashing branches when you merge them. - Do you want narrative documentation around strange choices? Fine-grained commits are a great place to put those thoughts, but they may discourage devs from writing those thoughts in inline comments. - Do you want ownership via git blame? Line-by-line changes may help you identify who wrote the code, but that might prevent your developers from ever fully transferring ownership, which could create bottlenecks in startups that have a few long-tenure devs and a lot of recently hired devs. I really like to think of git history as a context tool, like monitoring or unit testing or documentation. It's worthwhile to sit down with your team, define what you want them to be able to do with commit history, and build your commit style from there.
git 小提交让单条信息难写，整体描述应放在 squash 合并信息里
我的主观印象是：如今的提交越来越小。SVN 时代很多人一天只提交几次甚至几天一次，SVN 提交涉及与服务器同步（相当于 git 的 push），通常代表较大的代码变更。用 git 后，把改动拆成许多小提交变得很常见：改变量名？提交。写点文档？提交。整体改动没变小，只是分散到更多提交里，所以 SVN 的一次提交在概念上更接近现在的 pull request。这很重要，因为给一个变量重命名写长篇描述没什么意义。但我怀念的是对整体改动的描述——现在 merge commit 的描述往往只是自动生成的信息，而我希望大家在这里花时间充分描述改动。这也是我喜欢 --squash 合并的原因。我知道改写历史不好，但总的来说，我宁愿读一本历史书，也不想读 18 世纪的报纸。
data_hope查看英文原文
My personal, subjective impression: Commits are getting smaller and smaller nowadays. As in: In the subversion days, many people commited only few times a day, sometimes not for several days. SVN commits of course involved a sync with the server (a "push" in git lingo), and thus usually represented a much larger increment with a substantial change to the code base [X] With git, it became very common to structure changes to a code base in many, very small commits. Rename a variable? Commit. Write some docs? Commit. Of course, the overall changes when developing a feature did not become smaller, they are now just distributed over many more commits. So I'd argue that a SVN commit was often conceptionally closer to what we now have with a git pull-request. Why does this matter? Because It is kind of hard and not helping anyone if you describe your renaming of a local variable with an extensive docstring. What I do miss however, is a good description of the overall change. I.e. now often the description in the merge commit is just the autogenerated message, but this is where I would like people to really take the time and describe the change extensively. This is why I like `--squash` merges, because they let people focus on the relevant parts in their description. I know, rewriting history is bad, but overall, I favour reading a history book than 18th century newspapers. [X] not saying that there weren't small one-line-change commits, but overall they were rarer.
祈使句规则并非普适，区分系统行为与提交者行为更重要
在所有关于 Git 提交信息的常见建议中，我最难认同的是标题总是用祈使语气。用祈使句描述提交者自己的行为确实听起来奇怪，但更糟的问题是模糊了系统行为和提交者行为之间的区别。在我的项目里，描述系统应执行的动作时用祈使句（"Don't warn user about missing cache directory"），描述我自己做过的事时用陈述语气（"Removed unnecessary cache directory warning"）。有些项目两种情况都用祈使句，我怀疑这会给浏览提交日志带来额外的认知负担。
networked查看英文原文
Out of all common advice on Git commit messages always using the imperative mood in the title I find the hardest to agree with. Describing your own actions as a committer in the imperative may sound strange, true, but there is the worse problem of making less obvious the distinction between the actions of the system and those of the committer. In my own projects I use the imperative when describing the actions the system should perform ("Don't warn user about missing cache directory") but use the indicative mood when describing my own actions ("Removed unnecessary cache directory warning"). I've noticed that some projects use the imperative for both cases and I suspect this introduces a degree of cognitive overhead to scanning the commit log. One solution to this problem would be to never "address the system" in the commit title but I find that that is often the shortest and the most expressive way to describe an update.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选