在git中，有哪些好的约定可以将多个注释格式化为单个提交

我想知道人们通常如何在一次提交中分离出多个注释。星星？逗号？分开排队？只是想知道你发现什么是最好的

我现在在通过Emacs添加评论时使用这个，但不确定我是否喜欢它：

Added error messaging
Cleaned up sign-up UI
Added recaptcha

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Committer: Conrad Chu <chuboy@conradlaptop.local>
#
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       modified:   app/controllers/api_controller.rb
#       modified:   app/controllers/users_controller.rb
#       modified:   app/models/user.rb
#       modified:   app/views/users/new.html.erb
#       modified:   app/views/users/show.html.erb
#       modified:   config/environment.rb
#       modified:   db/migrate/20090923001219_create_users.rb
#       modified:   db/schema.rb
#       modified:   doc/README
#       modified:   public/stylesheets/master.css
#       new file:   vendor/plugins/recaptcha/.gitignore
#       new file:   vendor/plugins/recaptcha/CHANGELOG

添加了错误消息
清理注册用户界面
添加了recaptcha
#请输入更改的提交消息。起跑线
#将忽略带有“#”的消息，空消息将中止提交。
#
#提交人：朱康拉德
#
#论分行行长
#要提交的更改：
#（使用“git重置磁头…”取消分级）
#
#修改：app/controllers/api_controller.rb
#修改：app/controllers/users\u controller.rb
#修改：app/models/user.rb
#修改：app/views/users/new.html.erb
#修改：app/views/users/show.html.erb
#修改：config/environment.rb
#修改：db/migrate/20090923001219_create_users.rb
#修改：db/schema.rb
#修改：doc/README
#修改：public/stylesheets/master.css
#新文件：vendor/plugins/recaptcha/.gitignore
#新文件：vendor/plugins/recaptcha/CHANGELOG

Git对日志消息有很强的约定，但规则很简单：

第一行是提交的摘要

第一行可能有一个作用域描述前缀“module:”

第二行是空的

然后根据需要进行段落讨论

首先，您应该使用这些约定，因为演示工具甚至依赖于它们（第二行为空很重要，在许多情况下，您只能看到第一行摘要）

对于git，提交应该很小，因此第一个答案当然是，您不应该在一次提交中修改很多内容。您应该有三次提交，而不是一次

但是，你可以在提交日志中写一整篇文章，在那里你可以详细描述他们的变化（动机、放弃的设计、想法）。如果这三个变化真的属于一个整体，本文将阐明原因

---

我发现在描述相同的Git提交消息约定时，使用了Git命令依赖于特定格式的示例。（大部分都是基于现有的约定：通过电子邮件发送补丁。）

看这里，有提交指南和一个提交示例。

我必须同意@kaizer.se。使用git的能力将修改分阶段提交到3个不同的提交中。通过这种方式，您可以清楚地知道每次修改是什么，您的提交注释将告诉您为什么。在合并回主分支时（假设您使用功能模块的分支），您可以将这些较小的提交汇总到一个合并中。

我尽量不提交需要太多注释的更改，但如果需要，我通常会这样做：

Multiple changes:

- done this
- fixed that
- removed other

Maybe some additional explanations.

就功能而言，尽量保持提交的原子性。当我忘记在每个完成的特性之后实际提交时，我会为此准备大量的代码