众所周知的解决方案，将包管理的文件（例如node_modules/）添加到.gitignore文件中，以便将编译后的文件保留在本地而不是将它们添加到存储库中。但是，有时您确实想要签入某些文件，但不想每次在拉取请求中都看到这些文件。 对于这种情况（至少在 GitHub 上），您可以将用 linguist- generated 注释的路径添加到.gitattributes文件中，并在存储库的根目录中签入该文件。这将折叠拉取请求中的文件，因此您仍然可以看到它们已更改，但没有更改的完整内容。
任何减轻代码审查的压力和认知负担的方法都将有助于提高代码审查的质量并减少所需 特殊数据 的时间。 “ 例如，如果您有一个 Unity 项目，您可能想要签入资产文件，但实际上并不关心它们，因此您可以将其添加到属性文件中，如下所示： *.asset linguist-generated 复制 更频繁地使用 他关于 Git 的文章“我喜欢用 Git 做的小事”中建议的一个技巧。他说要使用别名git blame，git praise这样感觉就像是一个积极的行动。这看起来像是语义——重命名某些东西根本不会改变它的功能。但每当我看到任何团队谈论使用 Git 的指责功能时，每个人都会紧张，我当然也是如此。认为这是一件消极的事情是一种自然的反应……实际上不应该是这样！ 这是一个强大的功能，可以知道谁最后接触了您正在查看的代码。不是责备他们，甚至不是赞扬他们，而只是向正确的人提出问题，并节省时间来确定该与谁交谈。 您不仅应该将 git Blame 视为一件好事（如果您愿意，可以将其称为“赞扬”），而且您应该将其视为一种沟通工具，它将帮助整个团队减少混乱并防止浪费时间来弄清楚谁知道关于什么。
有些 IDE（例如 Visual Studio）包含此功能作为每个函数的注释（完全没有任何负面含义），因此您可以立即看到最后修改它的人（以及与谁讨论它）。 GIT 归咎于文件丢最近，我看到团队中的一名开发人员试图找出谁删除了文件、删除的时间以及删除的原因。这对于 git Blame 来说似乎是一个有用的时间，但它是基于文件中的行来工作的；它对不再存在的东西没有帮助。然而，有一个解决方案。旧的值得信赖的 git 日志。如果您查看不带参数的日志，那么您将看到当前分支上所有更改的一长串列表。您可以添加提交 ID 来查看该特定提交的日志，但如果您使用--（我们之前使用它来定位特定文件），那么您可以获得文件的日志 - 即使是不再存在的文件。 |
