我为什么要写一个提交消息？我不想，而且我认为它每次都很愚蠢。
我使用的GUI前端将不具名，它将迫使您执行此操作。即使他们在命令行上使用VCS，我每次都会听到其他人在这样做。
如果我每天提交几次，但是还没有完成功能，那我在写什么呢？我只有在多次提交后才写一条消息，我觉得是时候使用微型标签了，还是当我做一个实际的标签时。
我是对的还是我错过了什么？我也在使用分布式系统
Answers:
对于所有说“只有在您有有用的，经过深思熟虑的消息要编写，并且您的功能已完成100％并且有相应的单元测试时，才承诺”的人，我说：您仍处于SVN思维定势中。
如果您使用的是git，这就是我所说的智能工作流程：
git rebase -i从您添加的第一个“混乱”提交中，您可以通过挤压，编辑，省略和以其他方式将您的最近历史整理成带有精美消息的逻辑，干净的提交来添加并修复本地历史记录。请注意，第3步是结束您所需要的提交时，而使用SVN则必须放弃提交，直到完成前两个步骤为止，这是大多数其他答案所建议的。IOW，您不想将半编写的未经测试的代码强加给其他人，因此您无需花一个星期的时间，直到功能完成。您没有充分利用版本控制的潜力。
还要注意，在步骤1和3之间的任何位置，git push如果笔记本电脑的硬盘驱动器死了，您都可以在服务器上对自己的私有存储镜像进行更改，以获得免费的备份。
因为当一些可怜的维护者在寻找错误时，发现它是在rev中添加的。xyz，他将想知道什么转速。xyz应该做的。
您注释了源代码，对吗？
您写的是最好的注释，那些说为什么的注释，因为代码只说了怎么做？
提交消息就是这样的注释，因此，它非常重要，并且您对正确处理消息的投入越多，对将来的软件维护者越有用。
对于任何活动的软件，该特定注释最终都将以类似
（位于http://longair.net/blog/2009/04/25/a-few-git-tips/）。这样可以鸟瞰谁在何时开发了该软件，以及他们做了什么。
请注意，这是提交注释的最终目标，即显示在这样的列表中，向您的未来自己或您的同事说“ 什么 ”，这就是为什么您应该谨慎编写良好的提交消息的原因。
如果提交消息对您来说很愚蠢，则听起来您使用的提交错误。
提交应该有充分的理由-它们应该与您因使用的功能而分解的任务有关。无论这些任务是正式任务还是仅在您脑海中，您所做的每次更改都应或多或少地完成一项任务，并因此以某种方式起作用。
这样，您的提交消息便可以达到更好的目的。描述您完成的任务，如果未在其他地方跟踪到该任务，为什么需要该任务或该任务的目的：
然后，您或其他开发人员可以浏览存储库或文件的历史记录，并相当容易地看到发生了某些演变的原因以及原因。或者，如果发现某个特定修订版有错误，则提交消息将提供有关插入该行的原因的线索，这样您就不会仅仅撕掉它并可能破坏被认为是错误的内容。修复，您可以改正正确的方法。
提交评论并不能解决所有问题。他们总是有可能会尽其所能误导他人-尤其是当开发人员为不得不进入而感到生气时。尝试以下操作：将它们视为树林中的面包屑小径，登山路标或示踪子弹。做对了，他们可以勾勒出一条否则令人迷惑的道路。
不要从他们身上赚大钱。说实话：
保持简短和“大局”。如果可能，请参考功能/错误系统中的问题编号。一些版本控制UI包含用于此类操作的字段。
它减少了WTF /分钟的数量;）
转化为更快乐的团队（不讨厌您的团队），并可能以更低的成本获得更好的团队产出
因此，您团队的其他成员都知道WTF正在检查项目树中的更改。
因为如果您不练习输入体面的提交消息，您最终会像我的同事一样输入消息
no changes
要么
testing
提交了超过一百个已更改的文件（这里不是在开玩笑！）。
如果您成为这样的开发人员，那么无论您认为输入一条消息多么愚蠢，您在世界其他地方都会看起来很愚蠢。
想象一下您通过做出一些更改而破坏系统并在团队几次提交后意识到这一情况的情况。您不记得所做的更改，但是您记得在增强功能X或从模块Y中删除文件时可能出了一些问题。
但是不幸的是，修订号不会告诉您何时更改了X或Y。因此，您可以选择读取最近N天内提交的所有代码，或者仅阅读您编写的详细提交消息（比code更具可读性）。
因此，如果必须这样做，则在提交消息中写入相同，无聊，无用的，无关的文本比提交消息更有害。因为错误的消息没有找到错误的根源，而是会误导您。
因此，每次提交时都尝试编写有意义的提交消息，这对您和维护人员也有帮助。
如果您正在与其他人一起工作，那么提交消息对于实际查看其他人所做的事情非常重要：查找每个人的差异要花很多时间，而且您可能无法理解为什么有人这样做。如果您与其他人一起工作，而某人（也许不是您）必须回头看，例如，以自始至终的方式跟踪行为自上一版本以来的变化……您确实在不使用有用的提示的情况下使生活变得艰难信息。
如果您是一个人工作...在一个大部分按“原样”编码的项目中（例如，一个简单的网站或脚本），我或多或少都会看到您来自哪里。如果我从事类似的工作，那么我在继续进行某项工作时只关心日期/时间或最近的更改（您有一个还原点，但是这仅在开发过程中重要，在您实施它之后才重要）。版本控制只是进行一些备份的一种方法-我完全同意这并不能完全利用该系统-但是在某些小型项目中可能不需要。
在版本控制以两种不同的方式使用之前，我就想到了这一点，一种是记录项目中的更改，另一种是帮助开发人员就位……这两种完全不同。提交消息在一种方式中非常重要，而在另一种方式中可能几乎没有用。
你错过了什么。有必须是用于执行原因提交，否则你不会那样做。
您需要在注释中要做的就是将原因写成文字，即使仅仅是 wip: adding new state objects
像许多其他人一样，我在业余时间进行一些编码，并使用修订控制系统来跟踪我的开发和变更。我每周有空余的时间差异很大。在很多情况下，我连续几个星期甚至几个月都没有时间在项目上编码，而我通常会花费10分钟（典型的一天）到40分钟（美好的一天）之间的时间。这些条件当然不是很好-特别是对于调试问题。
保留不会丢失且易于检索的笔记至关重要。在每个会话结束时，将通过详细的消息来提交会话的工作。然后，我可以浏览提交历史并跟踪我的进度和思考过程。这使我能够以最少的宝贵时间来回去上周或上个月的位置。
我要说明的一点是，良好的提交消息可以帮助您（以及追随您的其他任何人）弄清发生了什么，发生了什么，发生了什么，最重要的是为什么。
从逻辑上考虑一下。当您提交时，这意味着已完成。如果您不留言，其他人将如何知道做了什么？
提交消息是了解该签入内容的快速方法，当他们想知道代码的哪个方面在哪个修订版本中有所更改时（可能由于某些原因），它们将对您团队中的其他开发人员有所帮助。
在相关说明中，我建议在提交消息中指定错误跟踪器的案例编号（我希望您使用的是一种），以便将来方便地跟踪事物。