版本提交当一个提交仅涉及一个文件时，有必要说明这个文件名称吗？

[nikoo]

比如一次提交修改了登录页面按钮的位置，涉及仅一个文件 /login.php

那么提交信息是：
1 、修改登录页面按钮的位置
2 、修改按钮位置

哪个比较合适呢？
方案 1 明显在版本提交信息整体阅读上方更为清晰，但问题是可以在版本控制中看到本次提交涉及修改的为 /login.php
那么，为最大化的避免冗余，方案 2 是否也是可以接受，或者说可能比方案 1 更为合理？

进一步考虑，如果认为1更为合理，那是否允许这样的提交信息出现？
“/login.php 修改按钮位置”

[just4test]

可读性、可读性、可读性。
当更改的文件很多时，我们依赖提交说明来理解本次提交的更改。
当文件足够少时，甚至不需要提交说明就可以理解。随便看眼代码更改就是了。

但很多时候，人们会希望**仅通过**提交说明来理解更改。比如浏览 branch 界面的时候。所以，我觉得 1 更为合适。

[dong3580]

写一下 commit 的内容[修改按钮位置]就行了,至于具体,查看源码对比上一次提交不就可以看到了.
没必要再还是行对行注释般的描述

[nikoo]

@just4test 那这种提交信息呢？“/login.php 修改按钮位置”
假设 /login.php 并不能很容易的用"登录页面"这样的直观的名字来转换的话呢？

[just4test]

@nikoo 我觉得没什么问题。注意保持风格统一就好。

[SpicyCat]

当然是方案一好。
commit message 要尽量简短同时信息量大。
说「修改按钮位置」这太笼统了，基本跟没写一样。
也不建议用 login.php ，而是用「登陆页面」，原因是文件名可能更改。

事实上，「修改登陆页面按钮位置」也不算好。 commit message 要写动机，还有空间的话，再写行为，也就是要简单说明下这个 commit 的目的是啥，具体做了啥倒不用写太详细。
比如你这个 commit ，为啥要修改按钮位置？总是有原因吧，也许是美化页面，也许是统一风格。

commit message 一般是要求不超过 80 字符，已经可以写两三句话了。不要总觉得写得越短越好。如果别人看一眼你的 message ，就知道你干了啥，而不用看 diff, 那说明你这个 message 很成功。

git log 有一种视图，仅罗列 commit message 首行。这种视图很紧凑，信息量大，但要求 message 写得好。