domain-list-community 贡献指南
???这东西还真的有人看!
从我加入 domain-list-community 的维护到现在是第五个月了,也帮助 dlc 完成了 v2ray 到 v2fly 的迁移。看到现在有新人加入维护,很开心。然后想着,我除了交 PR 还有 code review 以外,应该再做点什么。于是,就有了这篇 guideline。
以下内容属于个人观点。 即使我在 V2Fly 里,此篇文章也不代表官方。 |
Contribute
以下几点是你可以作为贡献的内容:
-
Fix Typo (修正拼写错误)
-
收集域名
-
分类域名
-
移除过期域名
修正拼写错误这个好理解,在此不做赘述。
收集域名通常有两种,一种就是为公司/组织创建新文件然后把域名写进去,另一种就是给现有的文件进行更新。
做个例子。第一种情况,你发现 xxx 公司没被 dlc 收录,那就可以创建一个文件命名为 xxx,然后把这家公司的域名给写进去;第二种情况,你发现了 xxxxxxx.com 归为 xxx 公司,但是 xxx 公司文件里并没有这个域名,你就可以写进去。
分类域名的话,目前 geolocation-cn
有很多暂时不知道如何处理的域名,你可以将它们分类到已有分类,或是新建分类,都可以。
移除过期域名这个比较好理解,一些失效的域名直接删除就可以了。
所有域名请按字典序排序。 |
接下来讲详细讲解每一个贡献内容的具体做法。
Fix Typo
参考 commit:dlc@ac8d2ee
所有的 Typo 都可以成为你提交 Pull Requests 的理由。例如 README 的 Typo,workflows 的 Typo,抑或是域名文件中注释的 Typo 、域名本身的 Typo,都可以。
收集域名
未被收录的域名经分类后都可以加入 dlc。dlc 有三个大类:
-
geolocation-cn,地理位置在中国 / 中国的组织 (公司)
-
geolocation-!cn,地理位置不在中国 / 中国的组织 (公司)
-
category-ads-all,用于广告的域名
geolocation-cn 的难度较小,最稳妥的情况,只需要 IP 在中国、有 ICP 备案且是中国的公司,就可以了。不确定的情况可以暂时不做收录。
geolocation-!cn 同理,创建新文件,分类,对在中国有固定接入点的域名加上 @cn
标签即可。
「在中国有特定接入点」的意思是,这个域名解析到一个中国 IP 上,无论它请求的 DNS 地理位置如何。通常来说,有一些泛域名会专门解析到中国地址,比如 data/apple
中收录的一些域名。还有一种情况就是 .cn
的 ccTLD,也可以加上去。
category-ads-all 是难度最大的,因为你需要确认这个域名的确是用于提供广告。广告域名在用户手上通常是直接路由到黑洞的,因此误判会造成很大的影响,PR 时也尽可能要加上说明。
交上去的域名确保是可用 / 正确归属。验证域名可用/归属的方式包括但不限于查询 whois,主动访问查看网页内容。 |
分类域名
在 geolocation-cn
里有一大堆让人看到头疼的域名,但 dlc 和 GFWlist 不太一样,不仅仅是域名一丢就完事了,因此 geolocation-cn
里也明说了 "TODO: Decide how to deal with these domains"。目前有一些已知分类和 category 文件,但是按照维护者咕咕咕的特性,这是给你水 PR 的好机会 (
geolocation-!cn
的分类做的还不错,当然欢迎你提出更精确的分类。
移除过期域名
这个也比较好理解。遇到失效的域名直接移除,交 PR,完事。
还有一些域名虽然没有失效,但访问的时候网页显示这个域名正在出售,也可以扔掉。
需要注意的事情
先引用一下 domain-list-community README 的原文:
Fork this repo, make modifications to your own repo, file a PR.
Please begin with small size PRs, say modification in a single file.
A PR must be reviewed and approved by another member.
After a few successful PRs, you may apply for manager access to this repository.
最最需要注意的事情是第二句,也就是:
-
small size PR,每个 Pull Request 没有必要的情况下应尽可能小
-
say modification in a single file,每一个域名文件的改动都需要专属的 commit 信息
small size PR
举个例子。你现在有一个 Typo 可以交 PR,同时你又有域名收集要交 PR,这两件不相关的事应该拆分成两个 PR。
而如果你在收集 XXX 公司的时候发现 XXX 公司有一个 XXX2 的子公司需要收集域名,那么这两件事一起做,交一个 PR。
如果一个 PR 范围非常大,将会提升 code review 的难度。因此不必要的时候,范围应尽可能的小。
say modification in a single file
commit 信息是为了说明做了哪些事情,但为了简洁,通常为每个文件的改动写单独的 commit 信息。
举个例子:dlc#55
在这个 Pull Request 中,主要工作是收集了 Akamai 公司的域名。但是新的域名文件是一定要包含在 geolocation / ads 里的,也就是说每创建一个新文件就至少需要修改两个文件。所以这个 PR 有两个 commit:
第一件事就是收集,第二件事就是 include 到 geolocation-!cn
里。
保持 commit 记录的整洁
GitHub lives matter.
如果一个 PR 中有 5 次 commit 按顺序分别是 1 2 3 4 5,做完所有 commit 之后发现 1 需要修改,简单的方法就是提交一个 6 commit,但是这样会多出一个本应该不存在的 commit,因此最好的方法是变基。如果你不会变基,那么可以 git reset --soft
之后再一起提交。千万注意,软还原是相当于执行了 git add
的,记得 restore 一下。
还有一种情况,就是你的 fork 可能有些时间了,交 PR 的时候有 conflict,那么可以先开一个主仓到 fork 的 Pull Request,进行变基消除 merge commit 后再进行 PR 的工作。
消除 merge commit 的步骤很简单,步骤可以看一看后记。
后记
域名基本知识
域名由子域名和顶级域组成,例如 so.com,.com 是顶级域,so 是子域名。但如果 so.com 还有更多的泛域名,都归为 so.com 所有。下方作为例子:
Querying Riddler for so.com subdomains
[CertSpotter] ipv6.www.so.com 240e:83:201:110:36:110:234:123
[CertSpotter] api.app.m.so.com 180.163.251.104
[CertSpotter] baike.so.com 36.110.234.91
[CertSpotter] zonghe.m.so.com 180.163.242.229
[Baidu] login.so.com 101.199.97.224
[CertSpotter] news.so.com 180.163.251.253
[Baidu] new.so.com 180.163.251.253
[Baidu] spro.so.com 180.163.237.98
[Baidu] wwww.so.com 104.192.110.226
[CertSpotter] www.so.com 104.192.110.226
[Baidu] ww2.so.com 104.192.110.226
[Baidu] helper.m.so.com 42.236.105.61
[CertSpotter] m.360video.so.com 42.236.9.99,112.64.200.23
[Baidu] top.so.com 42.236.9.99
[Baidu] mobile.so.com 112.64.200.104,240e:83:201:110:180:163:242:236
[Baidu] shouji.so.com 112.64.200.104,240e:83:201:110:180:163:242:236
[Baidu] sj.so.com 112.64.200.104,240e:83:201:110:180:163:242:236
[Baidu] trends.so.com 42.236.9.99
[Baidu] v.so.com 36.110.240.66
[Baidu] video.so.com 36.110.240.66
[Baidu] captcha.so.com 111.206.52.80
[Baidu] ww1.so.com 104.192.110.226
[Baidu] music.so.com 180.163.249.192
[Baidu] shipin.so.com 36.110.240.66
[Baidu] soft.so.com 104.192.110.203
[Baidu] vidio.so.com 36.110.240.66
[Baidu] w.so.com 104.192.110.226
[Baidu] ruanjian.so.com 104.192.110.203
[Baidu] m.baike.so.com 36.110.234.91
[Baidu] ww.so.com 104.192.110.226
[Baidu] sp.so.com 36.110.240.66
[CertSpotter] e.so.com 27.115.124.241
[Baidu] fanyi.so.com 180.163.251.253
[Baidu] xinzhi.wenda.so.com 36.110.236.195
[Alterations] s.m.so.com 42.236.105.61
[Baidu] liangyi.so.com 180.163.251.253
[Baidu] yl.so.com 180.163.251.253
[Baidu] en.so.com 180.163.251.253
[Baidu] ly.so.com 180.163.251.253
[Baidu] sug.m.so.com 180.163.242.28
so.com 有很多子域,不过在 dlc 的文件中,so.com
和 SwitchyOmega 的 *.so.com
是同一个意思,即包含所有子域,因此收录的时候只需要写 so.com
即可
确认域名可用
在审核 PR 的时候,经常会遇到直接访问打不开的情况,这是因为域名没有 A 记录或者是此域名不是用于网站访问的 (仅用于提供数据等)。
关于仓库的权限
当你熟悉了 dlc 的工作内容并有一定数量的 PR 后,欢迎你申请 dlc 仓库的读写权限。发 issue 或者联系我都可以。
消除 merge commit
开一个主仓到你自己的 fork 的 Pull Request
主仓 → Pull Requests → New Pull Request → compare across forks,在 base repository 中选择你的 fork。
Merge 时选择 merge commit
如果不选择 merge commit 的话,在你交 PR 的时候会出现很尴尬的局面。我上次选择了 rebase,然后尴尬得删除了一次 fork…… 也可能是我太菜了,好方法还请邮件告知我一下。
使用变基消除 Merge commit
首先 clone 你的 fork
git clone [email protected]:EpLiar/domain-list-community.git
接下来,查看 commit log
git log
由图可见,f77567d5e060711373d79bbada9768d9180a6ae7 是 merge commit,需要消除它。如果不进行消除,在交 PR 到主仓时会多出一个无用的 commit。于是我们进行变基,到 merge commit 的上一个 commit,也就是 299312766cb2d4780344d443c89044e2f0a2a4f4。
git rebase -i 299312766cb2d4780344d443c89044e2f0a2a4f4
# :wq in vim
成功变基并更新 refs/heads/master。
这时候会跳出 vim 编辑器,直接 :wq
退出即可。再次查看 commit log,merge commit 已经清除。
Punycode 转换
在收集域名的时候,通常会遇到非 ascii 字符的域名,然而 dlc 暂时不建议直接写其他语言,那么你需要一个 punycode 转换器。在此推荐一下 Punycode converter 。
CC BY 4.0
本文链接:https://epliar.com/articles/dlc-contribute-guideline/