TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Commit messages are not titles (2015)

76 点作者 arkadiytehgraet超过 5 年前

12 条评论

caseymarquis超过 5 年前
Commit messages are whatever an individual, community, or organization decides they should be. Debating beyond that is like debating tabs vs spaces. It doesn't matter as long as everyone you're working with is on the same page.
评论 #21831687 未加载
评论 #21831451 未加载
评论 #21835421 未加载
评论 #21831066 未加载
评论 #21831119 未加载
评论 #21832327 未加载
评论 #21831662 未加载
评论 #21832537 未加载
awolf超过 5 年前
&gt; If the first line of a commit message is a title, it changes the way you write it. It becomes just some text to introduce some more text, <i>without any stress on the information density</i>.<p>I agree with the author that commit messages should optimize for information density. However the example they provide does a poor job of this:<p>&gt; This is a smart synopsis, as information dense as possible.<p>&quot;This is a&quot; is the type of thing that should never appear in a commit message as it could apply to EVERY commit message. Synopsizing is the action, but doesn&#x27;t indicate what is being synopsized; one of the most important facts for someone to understand what is happening here. Finally &quot;as information dense as possible&quot;, again should also be cut as this is telling us HOW not WHAT (and ironically hurts information density).<p>Were I writing this example it would be:<p><pre><code> Synopsize how to write a commit message </code></pre> ---<p>I led an initiative at my current company to enforce all commit messages start with an imperative verb and be less than 72 characters. Some people hate it, some people love it.<p>Aside from standardization, the primary reason to do this is the imperative mood leads to the most concise sentence possible. By leading with the action, the most natural thing to do next is to talk about what is being acted upon. Unnecessary words are dropped and the most important facts are emphasized. In short it forces the author to get to the point.<p><pre><code> [Act] upon [some aspect of the code] </code></pre> e.g.<p><pre><code> Add user login link on home screen Refactor authentication into separate classes Lint PR titles conform to standard format</code></pre>
评论 #21831534 未加载
评论 #21831528 未加载
评论 #21833786 未加载
评论 #21832296 未加载
评论 #21831573 未加载
评论 #21832813 未加载
st_goliath超过 5 年前
There is probably no reasonable, generic guide on how to write commit messages, since different communities use git in different ways. So IMO this article is comparable to a discussion about indentation styles or text editors.<p>&gt; Commit messages are not titles<p>&gt; Nor subjects, for what matters.<p>&gt; ...<p>&gt; however many times there is <i>no</i> body, there is just the first line.<p>In Linux (the Kernel) development (where git actually came from), commits are sent as patches via e-mail to mailing list for review and for maintainers to pick them up.<p>The first line from the commit message becomes the subject line, the rest of the commit message and the diff becomes the body of the mail. The commit message should briefly explain <i>why</i> you are doing this, the <i>what</i> should be mostly in the diff itself. Having no body text after the first line for a non-trivial patch would be rather bad practice. Obviously the author of this article comes from a different background.<p>But then again, in different communities, a concise single line description with a ticket number may be enough.
mceachen超过 5 年前
Capturing the <i>reason why</i> something was changed, why this approach was chosen, and possibly enumerating other approaches not taken (and why they weren&#x27;t picked), are all gold to the Engineers of Tomorrow spelunking into some codebase.<p>Summarizing a diff frequently doesn&#x27;t add information that the diff itself already includes. Title or no title.<p>I&#x27;m surprised we don&#x27;t think about how to shout into the future more effectively. It might be ourselves that we&#x27;re helping the most.
评论 #21833399 未加载
sovietcattle超过 5 年前
Trying to impose &quot;one way&quot; to write commit messages is silly at best.<p>At work I follow whatever convention the team I&#x27;m on agrees with.<p>For my projects I use commit messages as a way to &quot;tag&quot; changes, more than to explain the changes using prose. That way it&#x27;s very easy for me to search for changes in the codebase.<p>eg. #event-loop #fix #multiple-dispatch #repeated-message (remove the # and you get the idea)
thrower123超过 5 年前
Most commit messages look like this:<p><pre><code> #1234 fixed the fucking fooinater that wouldn&#x27;t frobulate. </code></pre> Thank god for the hash ticket number linking standard. Unless you are working on the kernel, your context and discussions and notes are in the bugtracker, so there&#x27;s no very good reason to write an essay in the commit log.
评论 #21831589 未加载
mcguire超过 5 年前
The first comment:<p>&quot;<i>Every source control management system has its own rules. So what I say here for Git might not be valid for Mercurial, SVN, Bazaar, ...</i><p>&quot;<i>Git has a wonderful tool named format-patch, <a href="http:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git..." rel="nofollow">http:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git...</a>, that takes a commit and converts it to an email, to put it in a nutshell. Why is there a tool for that? Because Git was created to manage Linux kernel development, and that is done in most parts in or around the Linux Kernel Mailing List. So, the entanglement between commits and emails is deep rooted in Git. And yes, the first line of the commit message _is_ used as the subject.</i><p>&quot;<i>This explains, why you can google &quot;git commit message&quot; and find the same advice over and over again:</i><p>&quot;<i><a href="http:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git...*" rel="nofollow">http:&#x2F;&#x2F;git-scm.com&#x2F;docs&#x2F;git...*</a> &quot;</i><a href="https:&#x2F;&#x2F;github.com&#x2F;erlang&#x2F;o...*" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;erlang&#x2F;o...*</a> &quot;<i><a href="http:&#x2F;&#x2F;tbaggery.com&#x2F;2008&#x2F;04...*" rel="nofollow">http:&#x2F;&#x2F;tbaggery.com&#x2F;2008&#x2F;04...*</a><p>&quot;</i>&quot;No dot at the end, because it might end up as email subject, also use 50 chars or less.&quot;*<p>&quot;<i>I agree, that interpreting it as title for a longer commit message is a bad idea. The conciseness of this line is something important to be retained. A well-crafted email subject on the other hand makes in some cases reading the whole email unnecessary or only complimentary. (Yes, such things exist.) And that are the types of commit messages that we should strive for, ending with a dot or not.</i>&quot;
dang超过 5 年前
Discussed at the time: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9763463" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=9763463</a>
boomka超过 5 年前
Best practice advice used to be &quot;dont leave your commit message empty&quot; and now it seems headed in a direction of some kind of storytelling guide. Up next: the role of character development in your commit messages
评论 #21833892 未加载
xwdv超过 5 年前
Commit messages are not titles, or subjects, they are COMMANDS, written in the present tense, that describe exactly what will be done to the codebase if you merge in the commit. That’s pretty much all there is to say about it.
评论 #21831148 未加载
mc3超过 5 年前
Just use {JIRA Reference} - {JIRA title} and get on with your life.
评论 #21831288 未加载
gumby超过 5 年前
Why should a message subject not end with a period?