我觉得几乎每个人都使用编辑器(Vim,Notepad ++等)来获取Git提交消息.为什么？
我发现键入-m和几个引号很容易,并提供了一种简单的方法来重做提交(按向上箭头).我想在编辑器中进行多行提交消息会更容易,但我有足够的时间说服其他同事写任何消息!
Cas*_*bel 17
你提到了最重要的事情 - 长度.提交信息应主要永远是多行.唯一的例外是琐碎的提交(例如"将版本号提升到XXX")或合并没有冲突(尽管如此,附加短信并不是一个坏主意).就这样的事情而言,平均承诺应该超出主题一两句话; 有些甚至可以有段落.只要看一下git.git的日志 ; 它几乎可以保证成为提交消息样式和长度的一个很好的例子.
我意识到说服其他人编写好的提交消息可能很难,但这并不意味着你不能 - 而且你可能会发现使用编辑器编写它们会更容易.
(我在我的工作场所拥有完全相同的经验.我的同事首先是工程师,第二是程序员,版本控制用户......第三是慷慨.但你至少可以做好你的工作!)
一个合适的git提交消息应该几乎总是多行的.从官方的git-commit讨论,
虽然不是必需的,但最好使用一个简短(小于50个字符)的行来概括更改,然后是空白行,然后是更详尽的描述.例如,将提交转换为电子邮件的工具使用Subject:行的第一行和正文中的其余提交.
如果您很难获得任何提交消息,(与您的系统管理员和/或交谈)确保至少有一个GIT_EDITOR环境变量,core.editor配置变量,VISUAL环境变量或EDITOR环境变量设置为有用的东西.
一个选项是创建自己的"编辑器",提示短(<50个字符)描述,然后是最少数量的字符或句子.这可能不太受欢迎,但这取决于您的职位和工作环境的文化.
有些人有惯例,例如:
短(50个或更少)变化摘要
如有必要,可提供更详细的说明文 包装大约72个字符左右.在某些情况下,第一行被视为电子邮件的主题,其余文本被视为正文.将摘要与正文分开的空白行是至关重要的(除非您完全省略了正文); 像rebase这样的工具如果你把两者一起运行就会感到困惑.
用现在时写下你的提交信息:"修复bug"而不是"修复bug".此约定与git merge和git revert等命令生成的提交消息相匹配.
后面的段落是空行.
- 子弹点也没问题
- 通常使用连字符或星号作为子弹,前面有
一个空格,中间有空行,但惯例有所不同- 使用悬挂缩进
祝你好运,不使用编辑器.
| 归档时间： |
|
| 查看次数： |
4393 次 |
| 最近记录： |