标签 Github 下的文章

在 GitHub 网站上每天都会新增上百个项目。由于 GitHub 上有成千上万的项目,要在上面搜索好的项目简直要累死人。好在,有那么一伙人已经创建了一些这样的列表。其中包含的类别五花八门,如编程、数据库、编辑器、游戏、娱乐等。这使得我们寻找在 GitHub 上托管的项目、软件、资源、库、书籍等其他东西变得容易了很多。有一个 GitHub 用户更进了一步,创建了一个名叫 Awesome-finder 的命令行工具,用来在 awesome 系列的仓库中寻找超棒的项目和资源。该工具可以让我们不需要离开终端(当然也就不需要使用浏览器了)的情况下浏览 awesome 列表。

在这篇简单的说明中,我会向你演示如何方便地在类 Unix 系统中浏览 awesome 列表。

Awesome-finder - 方便地寻找 GitHub 上超棒的项目和资源

安装 Awesome-finder

使用 pip 可以很方便地安装该工具,pip 是一个用来安装使用 Python 编程语言开发的程序的包管理器。

在 Arch Linux 及其衍生发行版中(比如 Antergos,Manjaro Linux),你可以使用下面命令安装 pip

sudo pacman -S python-pip

在 RHEL,CentOS 中:

sudo yum install epel-release
sudo yum install python-pip

在 Fedora 上:

sudo dnf install epel-release
sudo dnf install python-pip

在 Debian,Ubuntu,Linux Mint 上:

sudo apt-get install python-pip

在 SUSE,openSUSE 上:

sudo zypper install python-pip

pip 安装好后,用下面命令来安装 'Awesome-finder'。

sudo pip install awesome-finder

用法

Awesome-finder 会列出 GitHub 网站中如下这些主题(其实就是仓库)的内容:

  • awesome
  • awesome-android
  • awesome-elixir
  • awesome-go
  • awesome-ios
  • awesome-java
  • awesome-javascript
  • awesome-php
  • awesome-python
  • awesome-ruby
  • awesome-rust
  • awesome-scala
  • awesome-swift

该列表会定期更新。

比如,要查看 awesome-go 仓库中的列表,只需要输入:

awesome go

你就能看到用 “Go” 写的所有流行的东西了,而且这些东西按字母顺序进行了排列。

你可以通过 上/下 箭头在列表中导航。一旦找到所需要的东西,只需要选中它,然后按下回车键就会用你默认的 web 浏览器打开相应的链接了。

类似的,

  • awesome android 命令会搜索 awesome-android 仓库。
  • awesome awesome 命令会搜索 awesome 仓库。
  • awesome elixir 命令会搜索 awesome-elixir。
  • awesome go 命令会搜索 awesome-go。
  • awesome ios 命令会搜索 awesome-ios。
  • awesome java 命令会搜索 awesome-java。
  • awesome javascript 命令会搜索 awesome-javascript。
  • awesome php 命令会搜索 awesome-php。
  • awesome python 命令会搜索 awesome-python。
  • awesome ruby 命令会搜索 awesome-ruby。
  • awesome rust 命令会搜索 awesome-rust。
  • awesome scala 命令会搜索 awesome-scala。
  • awesome swift 命令会搜索 awesome-swift。

而且,它还会随着你在提示符中输入的内容而自动进行筛选。比如,当我输入 dj 后,他会显示与 Django 相关的内容。

若你想从最新的 awesome-<topic>( 而不是用缓存中的数据) 中搜索,使用 -f-force 标志:

awesome <topic> -f (--force)

像这样:

awesome python -f

或,

awesome python --force

上面命令会显示 awesome-python GitHub 仓库中的列表。

很棒,对吧?

要退出这个工具的话,按下 ESC 键。要显示帮助信息,输入:

awesome -h

本文至此就结束了。希望本文能对你产生帮助。如果你觉得我们的文章对你有帮助,请将他们分享到你的社交网络中去,造福大众。我们马上还有其他好东西要来了。敬请期待!


via: https://www.ostechnix.com/easily-find-awesome-projects-resources-hosted-github/

作者:SK 译者:lujun9972 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

GitHub and all CI tools

持续集成(CI)工具可以帮助你在每次提交时执行测试,并将报告结果提交到合并请求,从而帮助维持团队的质量标准。结合持续交付(CD)工具,你还可以在多种配置上测试你的代码,运行额外的性能测试,并自动执行每个步骤,直到进入产品阶段

有几个与 GitHub 集成的 CI 和 CD 工具,其中一些可以在 GitHub Marketplace 中点击几下安装。有了这么多的选择,你可以选择最好的工具 —— 即使它不是与你的系统预集成的工具。

最适合你的工具取决于许多因素,其中包括:

  • 编程语言和程序架构
  • 你计划支持的操作系统和浏览器
  • 你团队的经验和技能
  • 扩展能力和增长计划
  • 依赖系统的地理分布和使用的人
  • 打包和交付目标

当然,无法为所有这些情况优化你的 CI 工具。构建它们的人需要选择哪些情况下服务更好,何时优先考虑复杂性而不是简单性。例如,如果你想测试针对一个平台的用特定语言编写的小程序,那么你就不需要那些可在数十个平台上测试,有许多编程语言和框架的,用来测试嵌入软件控制器的复杂工具。

如果你需要一些灵感来挑选最好使用哪个 CI 工具,那么看一下 Github 上的流行项目。许多人在他们的 README.md 中将他们的集成的 CI/CD 工具的状态显示为徽章。我们还分析了 GitHub 社区中超过 5000 万个仓库中 CI 工具的使用情况,并发现了很多变化。下图显示了根据我们的拉取请求中使用最多的提交状态上下文,GitHub.com 使用的前 10 个 CI 工具的相对百分比。

我们的分析还显示,许多团队在他们的项目中使用多个 CI 工具,使他们能够发挥它们最擅长的。

Top 10 CI systems used with GitHub.com based on most used commit status contexts

如果你想查看,下面是团队中使用最多的 10 个工具:

这只是尝试选择默认的、预先集成的工具,而没有花时间根据任务研究和选择最好的工具,但是对于你的特定情况会有很多很好的选择。如果你以后改变主意,没问题。当你为特定情况选择最佳工具时,你可以保证量身定制的性能和不再适合时互换的自由。

准备好了解 CI 工具如何适应你的工作流程了么?


via: https://github.com/blog/2463-github-welcomes-all-ci-tools

作者:jonico 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

上个月,我们用依赖关系图让你更容易跟踪你代码依赖的的项目,它目前支持 Javascript 和 Ruby。如今,超过 75% 的 GitHub 项目有依赖,我们正在帮助你做更多的事情,而不只是关注那些重要的项目。在启用依赖关系图后,当我们检测到你的依赖中有漏洞时会通知你,并给出来自 Github 社区中的已知修复。

Security Alerts & Suggested Fix

如何开始使用安全警报

无论你的项目时私有还是公有的,安全警报都会为团队中的正确人员提供重要的漏洞信息。

启用你的依赖图:

公开仓库将自动启用依赖关系图和安全警报。对于私人仓库,你需要在仓库设置中添加安全警报,或者在 “Insights” 选项卡中允许访问仓库的 “依赖关系图” 部分。

设置通知选项:

启用依赖关系图后,管理员将默认收到安全警报。管理员还可以在依赖关系图设置中将团队或个人添加为安全警报的收件人。

警报响应:

当我们通知你潜在的漏洞时,我们将突出显示我们建议更新的任何依赖关系。如果存在已知的安全版本,我们将通过机器学习和公开数据选择一个,并将其包含在我们的建议中。

漏洞覆盖率

CVE ID国家漏洞数据库公开披露的漏洞)的漏洞将包含在安全警报中。但是,并非所有漏洞都有 CVE ID,甚至许多公开披露的漏洞也没有。随着安全数据的增长,我们将继续更好地识别漏洞。如需更多帮助来管理安全问题,请查看我们的 GitHub Marketplace 中的安全合作伙伴

这是使用世界上最大的开源数据集的下一步,可以帮助你保持代码安全并做到最好。依赖关系图和安全警报目前支持 JavaScript 和 Ruby,并将在 2018 年提供 Python 支持。


via: https://github.com/blog/2470-introducing-security-alerts-on-github

作者:mijuhan 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

如果仓库不再活跃开发或者你不想接受额外的贡献,但这并不意味着你想要删除它。现在可以在 Github 上归档仓库让它变成只读。

归档一个仓库会让它对所有人只读(包括仓库拥有者)。这包括对仓库的编辑、 问题 issue 合并请求 pull request (PR)、标记、里程碑、项目、维基、发布、提交、标签、分支、反馈和评论。谁都不可以在一个归档的仓库上创建新的问题、合并请求或者评论,但是你仍可以 fork 仓库——以允许归档的仓库在其它地方继续开发。

要归档一个仓库,进入仓库设置页面并点在这个仓库上点击“ 归档该仓库 Archive this repository ”。

在归档你的仓库前,确保你已经更改了它的设置并考虑关闭所有的开放问题和合并请求。你还应该更新你的 README 和描述来让它让访问者了解他不再能够对之贡献。

如果你改变了主意想要解除归档你的仓库,在相同的地方点击“ 解除归档该仓库 Unarchive this repository ”。请注意归档仓库的大多数设置是隐藏的,你需要解除归档才能改变它们。

要了解更多,请查看这份文档中的归档仓库部分。归档快乐!


via: https://github.com/blog/2460-archiving-repositories

作者:MikeMcQuaid 译者:geekpi 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

又是一年,GitHub 例行发布了 2017 年度的章鱼猫观察报告。以下我们撷取此报告中一些有趣的结果分享给大家。

数百万的开发人员使用 GitHub 来共享代码和构建业务。在这里你可以完成你的工作、打造新的技术、贡献给开源项目等等。历史已经证明,当好奇的人聚集到一起工作,一些美好的事情就会随之而来:工作进行得更快、新的想法涌现,从根本上改变了我们建立软件的方式。

为了庆祝这贡献和辉煌的一年, 让我们回顾一下 2017 年的项目、人员和团队。

十年千万,遍及全球

过去这十年,GitHub 各项数据已经超过了百万级,甚至千万级。在 2017 年,GitHub 社区有 2400 万开发者工作于 6700 万个仓库上,就连这些开发者组成的组织都达到了 150 万个。

而这些开发者遍及全球:亚洲 710 万,北美 590 万,欧洲 530 万,等等。

这一年,忙碌的一年

人们在 2500 万个公开仓库上分享代码。从 2016 年 9 月到现在的一年间:

  • 公开仓库的提交数达到了 1 亿个
  • 活跃仓库有 2530 万个(“活跃”指该仓库有公开的活动,比如提交、星标、讨论等)
  • 活跃 工单 issue 有 1250 万个,关闭(解决)了 6880 万个工单,对工单进行了 140 万次讨论

  • 新 PR ( 拉取请求 pull request )有 130 万个,

  • 第 1 亿个 PR 被合并,这是一个 OpenShift 的文档更新
  • 对代码进行了 62 万次审查
  • 最流行的表情符是:点赞(720 万)
  • 新加入 670 万开发者,其有 100 万的开发者来自美国,69 万来自中国

    • 这些新加入的开发者发起了 120 万个 PR,410 万人创建了其第一个仓库,
    • 19 万人没有提交任何代码而只是复刻和星标了仓库
  • 创建了 45 万个组织

    • 这其中包括 Python 的开发也迁移到了 GitHub

编程语言,各就其位

通过 PR 所使用的语言,可以发现最流行的语言是——JavaScript!而 Python 取代了 Java 成为了第二名。很高兴 Ruby 和 PHP 分别能取得第四、第五名。其余的名次和去年相差不大。

项目排名,众望所归

从这些活跃的仓库中,我们找出了 10 大 复刻 fork 数最多的仓库。人工智能方向的 TensorFlow 项目夺得桂冠,前端方向的 BootStrap 是第二。尤雨溪的 vuejs 排名第六,恰恰比排名第七的 Facebook 的 react 的复刻数高一点,很难说这与今年 Facebook 对 react 的许可证问题有没有关系。而 Linus 的 Linux 项目敬陪末座,作为这样庞大的一个项目,已经相当了不起了。

(这里没有包括 MOOC 课程,一个 Coursera 的 R 语言课程有数千的复刻数,以此判断,至少有十万学生开始学习该课程了)

而以贡献者来说,微软的 vscode 项目的贡献者最多,几乎是排在第二名的 react-native 的两倍。这一方面证明了社区对 vscode 的喜爱,另外一方面也证明了微软在开源方面的重注投入。

得到最多代码评议的项目是 Typescript 的一个类型定义库 DefinitelyTyped,第二名才是炙手可热的 Kubernetes

当然,已经赢得了容器编排系统之战的 Kerbernetes 取得讨论最多的排名一点也不令人意外,它的讨论数量的零头就和第二名 origin 差不多,而这个 OpenShift 下的 Origin 项目,也是一个 Kubernetes 项目——面向开发者的企业版 Kubernetes 发行版。

企业版,大公司多用

GitHub 虽然对个人的公开使用提供免费的服务,当然,如果你想放私有仓库,是要交费的。而 GitHub 对于或大或小的企业来说,更适用的是其企业版。

  • 美国前一百个最大的公司(按收入)有一半在使用 GitHub 企业版
  • 虽然美国是使用 GitHub 企业版最多的国家,但是也有 1/4 的客户来自其它国家
  • 不仅仅是软件和互联网行业在使用 GitHub 企业版(占 22%),金融服务、商业服务也占比较高

感谢你,让我们期待 2018 年的章鱼猫报告!

在这篇分析报告中,我们将使用 2017 年度截止至当前时间(2017 年 10 月)为止,GitHub 上所有公开的推送事件的数据。对于每个 GitHub 用户,我们将尽可能地猜测其所属的公司。此外,我们仅查看那些今年得到了至少 20 个星标的仓库。

以下是我的报告结果,你也可以在我的交互式 Data Studio 报告上进一步加工

顶级云服务商的比较

2017 年它们在 GitHub 上的表现:

  • 微软看起来约有 1300 名员工积极地推送代码到 GitHub 上的 825 个顶级仓库。
  • 谷歌显示出约有 900 名员工在 GitHub 上活跃,他们推送代码到大约 1100 个顶级仓库。
  • 亚马逊似乎只有 134 名员工活跃在 GitHub 上,他们推送代码到仅仅 158 个顶级项目上。
  • 不是所有的项目都一样:在超过 25% 的仓库上谷歌员工要比微软员工贡献的多,而那些仓库得到了更多的星标(53 万对比 26 万)。亚马逊的仓库 2017 年合计才得到了 2.7 万个星标。

红帽、IBM、Pivotal、英特尔和 Facebook

如果说亚马逊看起来被微软和谷歌远远抛在了身后,那么这之间还有哪些公司呢?根据这个排名来看,红帽、Pivotal 和英特尔在 GitHub 上做出了巨大贡献:

注意,下表中合并了所有的 IBM 地区域名(各个地区会展示在其后的表格中)。

Facebook 和 IBM(美)在 GitHub 上的活跃用户数同亚马逊差不多,但是它们所贡献的项目得到了更多的星标(特别是 Facebook):

接下来是阿里巴巴、Uber 和 Wix:

以及 GitHub 自己、Apache 和腾讯:

百度、苹果和 Mozilla:

(LCTT 译注:很高兴看到国内的顶级互联网公司阿里巴巴、腾讯和百度在这里排名前列!)

甲骨文、斯坦福大学、麻省理工、Shopify、MongoDb、伯克利大学、VmWare、Netflix、Salesforce 和 Gsa.gov:

LinkedIn、Broad Institute、Palantir、雅虎、MapBox、Unity3d、Automattic(WordPress 的开发商)、Sandia、Travis-ci 和 Spotify:

Chromium、UMich、Zalando、Esri、IBM (英)、SAP、EPAM、Telerik、UK Cabinet Office 和 Stripe:

Cern、Odoo、Kitware、Suse、Yandex、IBM (加)、Adobe、AirBnB、Chef 和 The Guardian:

Arm、Macports、Docker、Nuxeo、NVidia、Yelp、Elastic、NYU、WSO2、Mesosphere 和 Inria:

Puppet、斯坦福(计算机科学)、DatadogHQ、Epfl、NTT Data 和 Lawrence Livermore Lab:

我的分析方法

我是怎样将 GitHub 用户关联到其公司的

在 GitHub 上判定每个用户所属的公司并不容易,但是我们可以使用其推送事件的提交消息中展示的邮件地址域名来判断。

  • 同样的邮件地址可以出现在几个用户身上,所以我仅考虑那些对此期间获得了超过 20 个星标的项目进行推送的用户。
  • 我仅统计了在此期间推送超过 3 次的 GitHub 用户。
  • 用户推送代码到 GitHub 上可以在其推送中显示许多不同的邮件地址,这部分是由 GIt 工作机制决定的。为了判定每个用户的组织,我会查找那些在推送中出现更频繁的邮件地址。
  • 不是每个用户都在 GitHub 上使用其组织的邮件。有许多人使用 gmail.com、users.noreply.github.com 和其它邮件托管商的邮件地址。有时候这是为了保持匿名和保护其公司邮箱,但是如果我不能定位其公司域名,这些用户我就不会统计。抱歉。
  • 有时候员工会更换所任职的公司。我会将他们分配给其推送最多的公司。

我的查询语句

#standardSQL
WITH
period AS (
  SELECT *
  FROM `githubarchive.month.2017*` a
),
repo_stars AS (
  SELECT repo.id, COUNT(DISTINCT actor.login) stars, APPROX_TOP_COUNT(repo.name, 1)[OFFSET(0)].value repo_name 
  FROM period
  WHERE type='WatchEvent'
  GROUP BY 1
  HAVING stars>20
), 
pushers_guess_emails_and_top_projects AS (
  SELECT *
    # , REGEXP_EXTRACT(email, r'@(.*)') domain
    , REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain
  FROM (
    SELECT actor.id
      , APPROX_TOP_COUNT(actor.login,1)[OFFSET(0)].value login
      , APPROX_TOP_COUNT(JSON_EXTRACT_SCALAR(payload, '$.commits[0].author.email'),1)[OFFSET(0)].value email
      , COUNT(*) c
      , ARRAY_AGG(DISTINCT TO_JSON_STRING(STRUCT(b.repo_name,stars))) repos
    FROM period a
    JOIN repo_stars b
    ON a.repo.id=b.id
    WHERE type='PushEvent'
    GROUP BY  1
    HAVING c>3
  )
)
SELECT * FROM (
  SELECT domain
    , githubers
    , (SELECT COUNT(DISTINCT repo) FROM UNNEST(repos) repo) repos_contributed_to
    , ARRAY(
        SELECT AS STRUCT JSON_EXTRACT_SCALAR(repo, '$.repo_name') repo_name
        , CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64) stars
        , COUNT(*) githubers_from_domain FROM UNNEST(repos) repo 
        GROUP BY 1, 2 
        HAVING githubers_from_domain>1 
        ORDER BY stars DESC LIMIT 3
      ) top
    , (SELECT SUM(CAST(JSON_EXTRACT_SCALAR(repo, '$.stars') AS INT64)) FROM (SELECT DISTINCT repo FROM UNNEST(repos) repo)) sum_stars_projects_contributed_to
  FROM (
    SELECT domain, COUNT(*) githubers, ARRAY_CONCAT_AGG(ARRAY(SELECT * FROM UNNEST(repos) repo)) repos
    FROM pushers_guess_emails_and_top_projects
    #WHERE domain IN UNNEST(SPLIT('google.com|microsoft.com|amazon.com', '|'))
    WHERE domain NOT IN UNNEST(SPLIT('gmail.com|users.noreply.github.com|qq.com|hotmail.com|163.com|me.com|googlemail.com|outlook.com|yahoo.com|web.de|iki.fi|foxmail.com|yandex.ru', '|')) # email hosters
    GROUP BY 1
    HAVING githubers > 30
  )
  WHERE (SELECT MAX(githubers_from_domain) FROM (SELECT repo, COUNT(*) githubers_from_domain FROM UNNEST(repos) repo  GROUP BY repo))>4 # second filter email hosters
)
ORDER BY githubers DESC

FAQ

有的公司有 1500 个仓库,为什么只统计了 200 个?有的仓库有 7000 个星标,为什么只显示 1500 个?

我进行了过滤。我只统计了 2017 年的星标。举个例子说,Apache 在 GitHub 上有超过 1500 个仓库,但是今年只有 205 个项目得到了超过 20 个星标。

这表明了开源的发展形势么?

注意,这个对 GitHub 的分析没有包括像 Android、Chromium、GNU、Mozilla 等顶级社区,也没有包括 Apache 基金会或 Eclipse 基金会,还有一些其它项目选择在 GitHub 之外开展起活动。

这对于我的组织不公平

我只能统计我所看到的数据。欢迎对我的统计的前提提出意见,以及对我的统计方法给出改进方法。如果有能用的查询语句就更好了。

举个例子,要看看当我合并了 IBM 的各个地区域名到其顶级域时排名发生了什么变化,可以用一条 SQL 语句解决:

SELECT *, REGEXP_REPLACE(REGEXP_EXTRACT(email, r'@(.*)'), r'.*.ibm.com', 'ibm.com') domain

当合并了其地区域名后, IBM 的相对位置明显上升了。

回音

接下来

我以前犯过错误,而且以后也可能再次出错。请查看所有的原始数据,并质疑我的前提假设——看看你能得到什么结论是很有趣的。

感谢 Ilya Grigorik 保留的 GitHub Archive 提供了这么多年的 GitHub 数据!

想要看更多的文章?看看我的 Medium在 twitter 上关注我 并订阅 reddit.com/r/bigquery试试 BigQuery,每个月可以免费分析 1 TB 的数据。


via: https://medium.freecodecamp.org/the-top-contributors-to-github-2017-be98ab854e87

作者:Felipe Hoffa 译者:wxy 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出