Git 写TODO来提交消息是一个好习惯吗？

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

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

例如，如果我必须切换到另一个作业，完成它并返回到此分支，我可以看到我未完成的内容，修复它，

commit--amend

，从提交消息中删除TODO语句

---

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

返回并调用

commit--amend

被认为是临时修复，而不是常规工作流

如果您

推送

已取消分支，则其他人看到的提交将无效

---

在问题跟踪器是一种过度使用的情况下——我完全理解这一点——只需以任何形式保留单独的TODO文件，例如纯文本标记，然后将其更改添加到您的代码提交中。

我认为这是次优的

考虑一下：如果TODO指的是代码，它应该在该代码段的旁边。如果在提交消息中写入，它将完全分离。当您的程序员同事想要实现TODO时，她如何确定在何处查找

如果TODO不是指代码，而是指基础结构、文档等，那么最好维护

TODO

文件，因为它更容易管理

• 查找活动待办事项列表
• 将项目移动到完成位置（例如，只需将其删除）

---

假设您想要一个待办事项列表。在您的方法中，是否可以grep所有提交消息？你怎么知道该做什么？一个单独的文件使这个答案非常简单。

你应该调查它是否对你的同事没有影响（你不推它等等），你只需要评估一下它的方便性。如果我将TODO添加到提交中，那么我应该从中删除已完成的项->

commit--amend

更改。我看不出将注释存储在文件和提交消息中有什么区别。编辑：好的，误解了你的答案。你是说我应该用不同的方式来美化自己。嗯，我不喜欢这样，但这是另一个问题（挤压还是不挤压）。@bimlas注意到，在许多环境中修改/修改提交消息是一个大禁忌，这是正确的。一般来说，历史是不可更改的，“一般来说，历史是不可更改的”：那么Git配置中的

rebase.autoSquash

的目的是什么？我认为有很多人更喜欢干净的日志，而不是每次提交。@bimlas不确定“提交每一点美化”的方法-这似乎是你自己的想法。在合并或类似操作完成后，我通常会提交大量代码并编辑TODO文件中的一行。因此，这是一个平均一个变化的注意到十几个提交。没有多少开销。YMMV将TODO作为注释编写似乎是个好主意（只是注意到我的IDE有一个专用的“TODO查找器”面板）。只是做了一个git别名来查找添加到当前分支中的TODO:

git--no pager diff--color words--no color--diff filter='AM'master | grep TODO | git grep-f--f2>/dev null