写 TODO 来提交消息是一个好习惯吗？ [关闭]

Posted 2023-02-21

【中文标题】写 TODO 来提交消息是一个好习惯吗？ [关闭]

【英文标题】：Is it a good habit to write TODO to commit message? [closed]

【发布时间】：2018-12-17 23:58:42

【问题描述】：

我刚刚意识到我更喜欢将 TODO 注释直接写入最新提交而不是问题跟踪器，例如：

TODO:
- Remove console.log
- Check that XY works
- ...

例如，如果我必须切换到另一个工作，完成它并返回这个分支，我可以看到我没有完成的工作，修复它，commit --amend，从提交消息中删除 TODO 语句。

这是一个好习惯还是我应该强迫自己使用问题跟踪器并在那里写下每一个小笔记（即使其他人可以看到问题）？

【问题讨论】：

你应该看看worktrees

如果不影响你的同事（你不推它等），这只是为了你评估它的便利性。

【参考方案1】：

我会说这是次优的。

考虑一下：如果 TODO 引用了代码，它应该在该段代码旁边。如果你把它写在一个提交消息中，它就会完全分离。当你的程序员同事想要实现 TODO 时，他们是如何确定在哪里寻找的？

如果 TODO 不是指代码，而是指基础设施、文档等，最好维护一个TODO 文件，因为这样更容易

查找活动 TODO 列表 将项目移至 DONE（例如，简单地删除它）

假设您想要一个 TODO 项目列表。在您的方法中，您可以 grep 所有提交消息吗？你怎么知道哪些 TODO 已经完成？一个单独的文件使这个答案变得超级简单。

【讨论】：

将 TODO 写成 cmets 似乎是个好主意（只是注意到我的 IDE 有一个专用的“TODO finder”面板）。

刚刚做了一个 git 别名来查找添加到当前分支的 TODO：git --no-pager diff --color-words --no-color --diff-filter='AM' master | grep TODO | git grep -f - -F 2> /dev/null

【参考方案2】：

返回并调用 commit --amend 被认为是用于临时修复，而不是用于常规工作流程。

如果您已经 pushed 您的分支，那么您将使其他人看到的提交无效。

在问题跟踪器过大的情况下 - 我完全可以理解 - 只需以任何形式保留单独的 TODO 文件，例如 markdown 的纯文本，然后将其更改添加到您的代码提交中。

【讨论】：

如果我将 TODO 添加到提交中，那么我应该从中删除已完成的项目 ->commit --amend 更改。我看不出将注释存储在文件和提交消息中之间的区别。 编辑：好的，误解了你的答案。所以你说我应该在不同的提交中提交每一个小美化。好吧，我不喜欢这样，但这是另一个问题（要压扁还是不压扁）。

@bimlas 请注意，修改/修改提交消息在许多环境中是一个很大的禁忌，这是正确的。总的来说，历史是不可改变的。

“历史一般是不可改变的”：那么在 Git 配置中 rebase.autoSquash 的目的是什么 - 我认为有很多人更喜欢干净的日志而不是保留每次提交。

@bimlas 不确定“提交每一个小小的美化”方法——这似乎是你自己的想法。一旦完成某些功能，在合并或类似之后，我通常会提交大量代码并在 TODO 文件上编辑一行。因此，十几个提交的注释平均变化一次。开销不大。 YMMV