开发功能时，通常需要更改不相关的文件：utils，helpers。但不仅如此。在某些情况下，某些存储库与功能不相关，但是它仅包含允许开发主要功能的其他代码。
起初，我只是跳过了这个问题。但是现在我明白，如果我更改了一些与我承诺的功能无关的文件，为什么我却很难理解。我需要像文件中的通常注释那样的东西，但是它们应该仅对git可见：当我浏览提交消息/历史记录时，我想看看为什么我做了特定的更改。我无法评论每个更改。最大的问题是，我的更改可能不仅是添加代码行，而且是删除代码行。没人需要查看缺席行的注释。
我的第一个想法是提交带有文件注释的更改，然后再次提交以删除注释。通过它就像一个解决方法。我在PhpStorm工作。而且我总是在那里看到git历史。我想从提交中打开文件，然后查看为什么进行了一些更改。我对我非常有用。很有用。对我来说，它从提交消息中获得的收益与我相同。
我看不到其他解决方案。也许其他人有这样的问题。
我还假设其他git GUI程序可能具有这样的功能。
嗯，为什么不使用git commit消息呢？
您可以通过放置许多-m参数在提交消息中添加几行：
git commit -m "My commit message (headline)" -m "Second line" -m "third line..."
或者如果您不想这样编写，可以设置编辑器，然后在运行git commit时，它将打开您的编辑器以编写您的长提交消息，因此您可以在其中解释所有需要的内容，为什么要这样做更改了文件等等。
要设置编辑器，只需运行：
git config core.editor vim
PS：我建议查看人们如何在大型存储库中编写提交消息，例如linux的存储库（https://github.com/torvalds/linux）。看看那里的消息是如何描述的，并受到启发：）
仅列出尝试的想法。
使用github或bitbucket的注释。他们很好。缺点是它们以服务器自己的格式存储，无法在本地访问。
使用说明；运行git notes add <commit>，然后有一个编辑器，您可以在其中插入（部分）差异并对其进行注释。它们存储在git的数据库中，如果您可以负担命令行的话，使用起来会相对方便。但是流行的工具在支持方面远远落后。
分别对您的帮助文件进行更改。这样，您就可以在专用位置发表评论。但是，那么您将不必压榨您的请求合并请求，这样就可以保留历史记录或创建单独的PR。
考虑重新组织您的助手，并使您必须接触到实现的内部。的确，如果它们具有特定于问题的功能，则将它们拆离很危险，有人可以出于不相关的目的开始使用它们。这样所做的更改看起来就没有那么多了。
Do not删除文件中的注释。如果某些操作从函数名称中不明显，则可以对它们背后的原因进行注释。