Github 关于贡献问题的文章没有关于--no-ff
合并的内容。
我在这个 reddit 线程中找到了一些答案,但过程对我来说仍然不清楚。
编辑:例如,我在功能分支中做了一些提交,然后我将此分支与主分支合并。Github 会计算我个人资料中功能分支的所有提交还是仅计算合并提交?
Github 关于贡献问题的文章没有关于--no-ff
合并的内容。
我在这个 reddit 线程中找到了一些答案,但过程对我来说仍然不清楚。
编辑:例如,我在功能分支中做了一些提交,然后我将此分支与主分支合并。Github 会计算我个人资料中功能分支的所有提交还是仅计算合并提交?
首先考虑一下倒数的--no-ff
含义:你正在做一个快进合并。
现在什么是快进合并?本质上,这意味着您只是在推进分支指针而不实际创建任何提交。由于提交是记录贡献的东西(因为它们保存作者/提交者信息),快速转发显然不会导致对存储库的可见提交贡献。
常见的存储库托管解决方案会跟踪对存储库的推送,因此您对分支的更新推送可以记录为贡献,但这通常不会这样做,因为它不能记录在存储库本身中。
因此,在查看非快进合并时,您实际上是在此处创建合并两个(或更多)分支的合并提交。合并提交,只是一个普通的提交,将正确记录提交者和作者信息,因此这可以算作贡献。
所以现在让我们来看看 GitHub 写了什么算是贡献:
如果满足以下所有条件,提交将出现在您的贡献图表上:
- 用于提交的电子邮件地址与您的 GitHub 帐户相关联。
- 提交是在独立的存储库中进行的,而不是分叉。
- 提交是:
- 在存储库的默认分支中(通常
master
)- 在
gh-pages
分支中(对于具有项目页面站点的存储库)
条件 1 由您的本地 Git 配置以及您设置 GitHub 帐户的方式处理。2 是不言自明的,而 3 本质上要求合并提交位于默认分支中。如果您要与 master 合并,这将起作用。
此外,以下至少一项必须为真:
- 您是存储库的协作者,或者是拥有该存储库的组织的成员。
- 您已经分叉了存储库。
- 您已在存储库中打开拉取请求或问题。
- 您已为存储库加注星标。
如果您对存储库具有某种推送访问权限(直接或作为拉取请求的一部分),也应该保证其中之一。
所以是的,合并提交应该算作贡献。