强化学习曾小健

同样都是merged commit “merged commit fc6f286 into InternLM:main last week”，同样在contribution里都有Contributions to main, excluding merge commits，怎么有的显示contributor，有的不显示不计入contributor使用squash mergecommits会被压缩成一个新的commitregular merge则不会创建新的commit。

1.不同的项目有各自的contributor计入规则2.尽量使用squash commit或rebase commit，而不要使用merge request。

如果您在 Git 上使用基于压缩的工作流程，则首席维护者可以在合并提交消息时清理提交消息 — 不会给临时提交者增加任何工作量。一种常见的工作流程是让您的 git 系统自动压缩来自拉取请求的提交，并为首席维护者提供一个表单，以便输入正确的 git 提交消息进行合并。常规提交规范是提交消息之上的轻量级约定。除此之外，常规提交的灵活性还允许您的团队提出自己的类型并随时间更改这些类型。本文档中的关键词“必须”、“不得”、“要求”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按照。

这里最大的风险是，任何本应被其他人的合并提交删除的文件或代码，如果仍留在你的分支中，可能会被重新添加。幸运的是，即使你这样做了，当你用这个功能分支发出拉取请求时，你的队友也会注意到你在 PR 上覆盖或删除的任何内容。如果您对这一切还不满意，您可以使用功能分支作为分支，在该分支中您将单独分支中的一系列提交与来自远程的提交合并。在基于主干或敏捷的开发中，尽量减少嘈杂的提交的数量以保持任何可能的回归易于回溯通常被认为是一种很好的做法。当你准备就绪后，你可以检出一个临时分支，其中包含所有功能分支的更改，但仍在。

有关更多信息，请参阅“具有“编辑存储库规则”权限的存储库管理员或自定义角色可以要求所有拉取请求在有人将拉取请求合并到受保护分支之前都获得特定数量的批准审核。如果评论中的建议超出了您的拉取请求的范围，您可以打开一个新问题来跟踪反馈并链接回原始评论。您可以在对话时间线中查看拉取请求收到的所有评论，并且可以在拉取请求的合并框中查看存储库所有者和合作者的评论。允许协作者对拉取请求中提出的更改进行评论、批准更改或在拉取请求合并之前请求进一步的更改。或者您对打开拉取请求的存储库具有写权限，则可以解决拉取请求中的对话。

如果contributor超过100人，而你的贡献代码量在100名开外，是显示不出的。