小提交消息还是大提交消息？
几天前，我和我的朋友讨论了使用版本控制系统时提交消息的大小。当他使用较大的提交消息但不那么频繁地提交时，我就有了经常提交和小提交的想法。
我总是听说，至少作为初学者，你应该按照我的方式去做；经常有小的提交消息。如果可能的话，您应该用一句话总结您的提交。
但当我看到 Linus Torvalds 这样的专业人士时，我却得到了相反的感觉。以下是他在 github 上的 subsurface 项目上提交的一条消息。
如果它们在半个以内，这使得它认为它们是相同的 互相吧。如果您手动编辑压力并将其设置为 与样品相同的巴压力，它们可能与样品不同 最后毫巴，但显然手动输入的气缸压力不是 与样本数据显着不同，因此认为它是多余的。
我们确实希望手动超越气缸压力 通过样本数据（正如 Dirk 雄辩地指出的那样，一些潜水电脑 确实没有非常可靠的样本数据），但同时 样本数据是我们期望相当准确的数据。这 开始和结束压力覆盖适用于没有样品时 数据，或者样本数据由于某种原因完全错误。
签署人：Linus Torvalds
这里是有问题的提交消息。
我查看了自己的提交消息（我有几千条），它们通常总是少于 40 个字符。
有人对这个问题有意见吗？
I friend of mine and I had a discussion a few days back about the size of a commit message when using version control systems. I had the idea of committing often and small when he on the other hand used larger commit message but instead committed not so often.
I've always heard that you should, at least as a beginner, do it my way; small commit messages often. You should, if possible, summarize your commit in one sentence.
But I get the opposite feeling when looking at pro's like Linus Torvalds. Here is one commit message from him on the subsurface project on github.
This makes it consider them to be identical if they are within half a
bar of each other. If you edit the pressures by hand and set them to
the same bar pressure as the samples, they may not be identical to the
last milli-bar, but clearly the manually entered cylinder pressure isn't
significantly different from the sample data, so consider it redundant.
We do want manual overrides of cylinder pressures to take precedence
over sample data (as Dirk so eloquently puts it, some dive computers
really don't have very reliable sample data), but at the same time the
sample data is the one we are expecting to be fairly accurate. The
starting and ending pressure overrides are for when there is no sample
data, or when the sample data is totally wrong for some reason.
Signed-off-by: Linus Torvalds
Here is the commit message in question.
I took a look at my own commit message (I've a few thousand of them) and they are most often always less than 40 characters.
Anyone got some input on the question?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您需要考虑提交消息的受众。
如果你是唯一一个对你的项目感兴趣的人，那么你想写多少就写多少——你只需要足够的内容来提醒自己为什么在六个月后选择了一种方法。当您想要寻找错误时，您只需要足够的信息即可找到哪个特定提交更改了哪个特定功能。
如果您正在与一个可能为数十或数百人服务的团队一起编写软件，那么提交消息可能应该更有意义。 （这并不总是意味着更长，但它确实意味着要不惜一切代价避免“修复愚蠢的错误”——“不要超出堆栈缓冲区“名称””要好得多，而且几乎 。
Linus 的提交消息可能看起来很大，但他并不冗长或冗长 他言辞简洁，切中要点。他正在为数以千计或数以百万计的程序员、发行版打包者以及您在特定的提交消息中发现的、终生依赖他的代码的潜水者写作。他们想要比 MMORPG 签入更好的提交消息。
You need to consider the audience for your commit messages.
If you are the only person ever to be interested in your projects, write as little as you feel like -- you just need enough to remind yourself why you chose one approach over another six months from now. You need just enough to find which specific commit changed which specific feature when you want to go bug-hunting.
If you are writing software with a team that might serve dozens or hundreds of people, the commit messages should probably be more meaningful. (This doesn't always mean longer, but it does mean "fix silly bug" is to be avoided at all costs -- "don't overrun stack buffer 'name'" is far better and almost as quick to type.)
Linus's commit messages might look huge, but he is not verbose or wordy. He's concise and gets to the point. He is writing for thousands or millions of programmers, distribution packagers, and in the specific commit message you found, divers who depend on his code for their life. They want better commit messages than might be demanded of a MMORPG checkin.
提交消息的大小与您应该提交的频率几乎没有关系。
关于提交频率的普遍共识是经常提交更好，但是您应该只提交有效的代码（或者至少可以编译并且不会破坏任何内容）。
请注意，git 允许您将多个提交“压缩”为单个提交，这样您就可以获得经常提交（任何时候都不会有许多未提交的更改）和仅提交完整功能（更容易理解提交历史记录）的好处
。消息，更多的信息总是好的，但当然应该权衡它所需的努力，
提交消息的要点是对更改的内容进行非常简短的概述（以便您在查看时可以决定它是否对您感兴趣。提交历史记录），以及解释为什么要在提交中进行更改，但如果问题/错误跟踪系统或设计文档中有相应的条目，那就更好了。参考那个。
The size of commit messages has almost nothing to do with how often you should commit.
The general consensus on commit frequency is that committing often is better, but you should commit only code that works (or at least compiles and doesn't break anything).
Note that git allows you to "squash" multiple commits into a single one, so that you get the benefit of committing often (not having many uncommitted changes at any time) and committing only complete features (more easily understood commit history.
As for commit messages, more information is always good but of course should be weighed against the effort it requires.
The point of a commit message is to give a very brief overview of what was changed (so that you can decide whether it's interesting to you when looking at the commit history), and explain why the change in the commit was done. Linus' message does this in great detail. But if there is a corresponding entry in an issue/bug tracking system, or a design document, it would be better to refer to that.
我更喜欢带有原子提交的较小提交消息。做出小而简洁的改变。他们不需要太多解释。编写代码，如果需要解释，请让注释来说话。很难扫描包含大量消息的提交。只要你解释了正在发生的事情的要点，那就足够了。我想这确实可以归结为个人喜好。
I prefer smaller commit messages with atomic commits. Commit small, succinct changes. They don't require much explanation. Write the code, and if it needs explaining let the comments do the talking. It's hard to scan commits with huge messages. As long as you explain the gist of what's going on, that should be good enough. I guess it does boil down to personal preference though.
我的提交大小取决于我的任务。
我尝试将类似的更改集中到一次提交中。因此，消息仅描述我开发的功能（没有冗长乏味的故事）。
Size of my commits depends on my tasks.
I try group similar changes in one commit. So, messages only describes features that I develop (without long and boring stories).
我发现少而频繁是最有效的
Little and often is what I find works best