Audacious 是一个开源音频播放器，可用于包括 Linux 在内的多个平台。继上次发布主版本将近 2 年后，Audacious 4.0 带来了一些重大变化。

最新版本的 Audacious 4.0 默认带 Qt 5 用户界面。你仍然可以和以前一样使用旧的 GTK2 UI，但是，新功能仅会添加到 Qt UI 中。

让我们看下发生了什么变化，以及如何在 Linux 系统上安装最新的 Audacious。

Audacious 4.0 关键变化和功能

当然，主要的变化是默认使用 Qt 5 UI。除此之外，他们的官方公告中提到了许多改进和功能补充，它们是：

• 单击播放列表列头可对播放列表进行排序
• 拖动播放列表列头会更改列顺序
• 应用中的音量和时间步长设置
• 隐藏播放列表标签的新选项
• 按路径对播放列表排序，现在将文件夹排序在文件后面
• 实现了额外的 MPRIS 调用，以与 KDE 5.16+ 兼容
• 新的基于 OpenMPT 的跟踪器模块插件
• 新的 VU Meter 可视化插件
• 添加了使用 SOCKS 网络代理的选项
• 换歌插件现在可在 Windows 上使用
• 新的“下一张专辑”和“上一张专辑”命令
• Qt UI 中的标签编辑器现在可以一次编辑多个文件
• 为 Qt UI 实现均衡器预设窗口
• 歌词插件获得了在本地保存和加载歌词的能力
• 模糊范围和频谱分析器可视化已移植到 Qt
• MIDI 插件 “SoundFont 选择”已移植到 Qt
• JACK 输出插件获得了一些新选项
• 添加了无限循环 PSF 文件的选项

如果你以前不了解它，你可以轻松安装它，并使用均衡器和 LADSP 效果器来调整音乐体验。

如何在 Ubuntu 上安装 Audacious 4.0

值得注意的是，非官方 PPA 是由 UbuntuHandbook 提供的。你可以按照以下说明在 Ubuntu 16.04、18.04、19.10 和 20.04 上进行安装。

1、首先，你必须在终端中输入以下命令将 PPA 添加到系统中：

sudo add-apt-repository ppa:ubuntuhandbook1/apps

2、接下来，你需要从仓库中更新（刷新）软件包信息，然后继续安装该应用。方法如下：

sudo apt update
sudo apt install audacious audacious-plugins

就是这样。你无需执行其他任何操作。无论什么情况，如果你想删除 PPA 和软件，只需按顺序输入以下命令：

sudo add-apt-repository --remove ppa:ubuntuhandbook1/apps
sudo apt remove --autoremove audacious audacious-plugins

你也可以在它的 GitHub 页面上查看有关源码的更多信息，并根据需要在其他 Linux 发行版上进行安装。

• Audacious 源代码

总结

新功能和 Qt 5 UI 开关对于改善用户体验和音频播放器的功能应该是一件好事。如果你是经典 Winamp 界面的粉丝，它也可以正常工作。但缺少其公告中提到的一些功能。

你可以尝试一下，并在下面的评论中让我知道你的想法！

via: https://itsfoss.com/audacious-4-release/

作者：Ankush Das 选题：lujun9972 译者：geekpi 校对：wxy

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

Linus Torvalds 升级主力电脑，15 年来首次不用英特尔处理器

在近日发布的 Linux Kernel 5.7 rc7 帖子中，托瓦兹表示主力电脑将不再使用英特尔的 CPU 了：“事实上本周对于我来说最大的兴奋点就是我升级了主力电脑，而且这是我 15 年来首次更换到非英特尔平台。我目前还没有切换到 ARM，不过我现在使用的是 AMD 的 Threadripper 3970x。我的 allmodconfig 测试版速度要比此前快了 3 倍。在这段平静期还无法突显出来，不过相信在下个窗口合并期将会有明显的升级。”

来源：cnBeta.COM

硬核老王点评：Linus 作为最大的开源领袖之一，其一举一动都极引人瞩目。Linus 换了新电脑，是不是会加速 Linux 内核的开发工作呢？毕竟大神可能会花费更少的时间来等待内核编译完成~

世界上使用量最大的数据库引擎 SQLite 3.32.0 发布

SQLite 是一个 C 实现的 SQL 数据库引擎，它的特点是小型、快速、自包含、高可靠性和功能齐全。SQLite 嵌入在所有手机和大多数计算机中，也捆绑在为数众多的其它应用中，是世界上使用量最大的数据库引擎。

来源：开源中国

硬核老王点评：这个不起眼的小型数据库，因其体型小而得到广泛使用，就像 MINIX 是世界上使用最多的操作系统一样，让很多人吃惊。

民间高手魔改卡西欧计算器遭版权组织警告

来自印度的 Neutrino 动手将一台卡西欧计算器（fx-ms991）的太阳能充电面板改造为显示屏，借助 esp 元件、Firebase 编程开发，可以通过这块屏幕连接互联网并收发即时消息。随后，改写代码等也被放上了 GitHub，供在家无聊但有兴趣的朋友效仿借鉴。然而，版权保护组织 REACT 本周出面，声称 Neutrino 托管的代码中并非全部是开源项目，有些是卡西欧专有的私产，不允许公开使用，虽然 Neutrino 坚称自己完全是从零写的程序。

来源：快科技

硬核老王点评：应该鼓励这种黑客精神，建议卡西欧和 REACT 对这种情况高抬贵手。

OpenCV 开源许可协议拟从 BSD 变更为 Apache 2

OpenCV 开发团队目前正在讨论变更开源许可协议的详细问题，预计在 6 月 29 日进行第一次评估。BSD 许可协议比较宽松，对于采用 BSD 的开源项目，开发者使可以自由使用、修改源码，也可以将修改后的代码作为开源或者专有软件再发布，不过需要保留当前许可内容。然而 BSD 许可协议在某些情况下（例如涉及到专利）却无法保护用户。

来源：开源中国

硬核老王点评：宽松自由的 BSD 许可证，是不是对开源最有利，这个要全面来看待。

看看这个很酷的 Kubernetes 管理的终端 UI。

通常情况下，我写的关于 Kubernetes 管理的文章中用的都是做集群管理的 kubectl 命令。然而最近，有人给我介绍了 k9s 项目，可以让我快速查看并解决 Kubernetes 中的日常问题。这极大地改善了我的工作流程，我会在这篇教程中告诉你如何上手它。

它可以安装在 Mac、Windows 和 Linux 中，每种操作系统的说明可以在这里找到。请先完成安装，以便能够跟上本教程。

我会使用 Linux 和 Minikube，这是一种在个人电脑上运行 Kubernetes 的轻量级方式。按照此教程或使用该文档来安装它。

设置 k9s 配置文件

安装好 k9s 应用后，从帮助命令开始总是很好的起点。

$ k9s help

正如你在帮助信息所看到的，我们可以用 k9s 来配置很多功能。我们唯一需要进行的步骤就是编写配置文件。而 info 命令会告诉我们该应用程序要在哪里找它的配置文件。

$ k9s info
 ____  __.________
|    |/ _/   __   \______
|      < \____    /  ___/
|    |  \   /    /\___ \
|____|__ \ /____//____  >
        \/            \/

Configuration:   /Users/jess/.k9s/config.yml
Logs:            /var/folders/5l/c1y1gcw97szdywgf9rk1100m0000gn/T/k9s-jess.log
Screen Dumps:    /var/folders/5l/c1y1gcw97szdywgf9rk1100m0000gn/T/k9s-screens-jess

如果要添加配置文件，该配置目录不存在的话就创建它，然后添加一个配置文件。

$ mkdir -p ~/.k9s/
$ touch ~/.k9s/config.yml

在这篇介绍中，我们将使用 k9s 版本库中推荐的默认 config.yml。维护者请注意，这种格式可能会有变化，可以在这里查看最新版本。

k9s:
  refreshRate: 2
  headless: false
  readOnly: false
  noIcons: false
  logger:
    tail: 200
    buffer: 500
    sinceSeconds: 300
    fullScreenLogs: false
    textWrap: false
    showTime: false
  currentContext: minikube
  currentCluster: minikube
  clusters:
    minikube:
      namespace:
        active: ""
        favorites:
        - all
        - kube-system
        - default
      view:
        active: dp
  thresholds:
    cpu:
      critical: 90
      warn: 70
    memory:
      critical: 90
      warn: 70

我们设置了 k9s 寻找本地的 minikube 配置，所以我要确认 minikube 已经上线可以使用了。

$ minikube status
host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

运行 k9s 来探索一个 Kubernetes 集群

有了配置文件，并指向我们的本地集群，我们现在可以运行 k9s 命令了。

$ k9s

启动后，会弹出 k9s 的基于文本的用户界面。在没有指定命名空间标志的情况下，它会向你显示默认命名空间中的 Pod。

如果你运行在一个有很多 Pod 的环境中，默认视图可能会让人不知所措。或者，我们可以将注意力集中在给定的命名空间上。退出该应用程序，运行 k9s -n <namespace>，其中 <namespace> 是已存在的命名空间。在下图中，我运行了 k9s -n minecraft，它显示了我损坏的 Pod：

所以，一旦你有了 k9s 后，有很多事情你可以更快地完成。

通过快捷键来导航 k9s，我们可以随时使用方向键和回车键来选择列出的项目。还有不少其他的通用快捷键可以导航到不同的视图。

• 0：显示在所有命名空间中的所有 Pod
• d：描述所选的 Pod
• l：显示所选的 Pod 的日志

你可能会注意到 k9s 设置为使用 Vim 命令键，包括使用 J 和 K 键上下移动等。Emacs 用户们，败退吧 :)

快速查看不同的 Kubernetes 资源

需要去找一个不在 Pod 里的东西吗？是的，我也需要。当我们输入冒号（:）键时，可以使用很多快捷方式。从那里，你可以使用下面的命令来导航。

• :svc：跳转到服务视图
• :deploy：跳转到部署视图
• :rb：跳转到角色绑定视图，用于 基于角色的访问控制（RBAC）管理
• :namespace：跳转到命名空间视图
• :cj：跳转到 cronjob 视图，查看集群中计划了哪些作业。

这个应用最常用的工具是键盘；要在任何页面往上或下翻页，请使用方向键。如果你需要退出，记得使用 Vim 绑定键，键入 :q，然后按回车键离开。

用 k9s 排除 Kubernetes 的故障示例

当出现故障的时候，k9s 怎么帮忙？举个例子，我让几个 Pod 由于配置错误而死亡。下面你可以看到我那个可怜的 “hello” 部署死了。当我们将其高亮显示出来，可以按 d 运行 describe 命令，看看是什么原因导致了故障。

草草掠过那些事件并不能告诉我们故障原因。接下来，我按了 esc 键，然后通过高亮显示 Pod 并输入shift-l 来检查日志。

不幸的是，日志也没有提供任何有用的信息（可能是因为部署从未正确配置过），而且 Pod 也没有出现。

然后我使用 esc 退了出来，我看看删除 Pod 是否能解决这个问题。要做到这一点，我高亮显示该 Pod，然后使用 ctrl-d。幸好 k9s 在删除前会提示用户。

虽然我确实删除了这个 Pod，但部署资源仍然存在，所以新的 Pod 会重新出现。无论什么原因（我们还不知道），它还会继续重启并死掉。

在这里，我会重复查看日志，描述资源，甚至使用 e 快捷方式来编辑运行中的 Pod 以排除故障行为。在这个特殊情况下，失败的 Pod 是因为没有配置在这个环境下运行。因此，让我们删除部署来停止崩溃接着重启的循环。

我们可以通过键入 :deploy 并点击回车进入部署。从那里我们高亮显示并按 ctrl-d 来删除。

这个有问题的部署被干掉了! 只用了几个按键就把这个失败的部署给清理掉了。

k9s 是极其可定制的

这个应用有很多自定义选项、乃至于 UI 的配色方案。这里有几个可编辑的选项，你可能会感兴趣。

• 调整你放置 config.yml 文件的位置（这样你就可以把它存储在版本控制中）。
• 在 alias.yml 文件中添加自定义别名。
• 在 hotkey.yml 文件中创建自定义热键。
• 探索现有的插件或编写自己的插件。

整个应用是在 YAML 文件中配置的，所以定制化对于任何 Kubernetes 管理员来说都会觉得很熟悉。

用 k9s 简化你的生活

我倾向于以一种非常手动的方式来管理我团队的系统，更多的是为了锻炼脑力，而不是别的。当我第一次听说 k9s 的时候，我想，“这只是懒惰的 Kubernetes 而已。”于是我否定了它，然后回到了到处进行人工干预的状态。实际上，当我在处理积压工作时就开始每天使用它，而让我震惊的是它比单独使用 kubectl 快得多。现在，我已经皈依了。

了解你的工具并掌握做事情的“硬道理”很重要。还有一点很重要的是要记住，就管理而言，重要的是要更聪明地工作，而不是更努力。使用 k9s，就是我践行这个目标的方法。我想，我们可以把它叫做懒惰的 Kubernetes 管理，也没关系。

via: https://opensource.com/article/20/5/kubernetes-administration

作者：Jessica Cherry 选题：lujun9972 译者：wxy 校对：wxy

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

谷歌工程师：七成 Chrome 安全漏洞是内存安全问题

近日，有谷歌工程师分析了自 2015 年以来在 Chrome 稳定版分支中修复的 912 个安全错误。并发现，在这些被标记为“高”或“严重”等级的所有安全漏洞中，大约 70％ 是内存管理和安全问题。 这一数据恰巧与微软此前的研究结果相同：微软安全响应中心（MSRC）对自 2004 年以来所有报告过的微软安全漏洞进行了分类，所有微软年度补丁中约有 70% 是针对内存安全漏洞的修复程序。

来源：开源中国

硬核老王点评：内存问题是永恒的安全问题，所以， C/C++ 这种自我管理内存的编程语言，已经越来越面临更大的挑战，因此，Rust 得到青睐也是可以预期的。

勒索事件追踪：4200 万美金成交！ 黑客声称特朗普“脏衣服”被买走

据外媒报道，此前，黑客以 2100 万美金勒索纽约 Grubman Shire Meiselas＆Sacks 事务所无果后，声称有特朗普的黑历史，并以 4200 万美金发起新一轮的勒索。近日，该黑客组织声称已经将美国总统特朗普的“黑历史”卖给了一位神秘买家。

来源：E安全

开源图形编辑器 Krita 首个测试版登陆 Play 商城

该测试版基于 Krita 4.2.9 桌面版，具备和桌面版相同的完整功能。不过值得注意的是，此版软件兼容 Android 平板和 Chromebook 设备，暂不支持Android手机。此外，它并未对平板设备进行触控优化，因此还需要等待后续版本的改进。

来源：cnBeta.COM

硬核老王点评：桌面版要移植到手机上，需要做很多的工作，但是自从平板设备和触控操作尚属可行。

Git 和 GitHub 已经成为了开发者的基础工具，尤其是参与开源软件开发时经常会使用它们。但是在 Git 和 GitHub 使用过程中遇到的很多术语并没有标准的或约定俗成的中文译名，因此，我们根据 GitHub 、Git 等文档，并结合我们的翻译惯例，收集整理了 Git 和 GitHub 中常用术语的中文译名及其解释。

这里值得注意是术语有复刻、挂钩、议题、星标、变基、仓库等，这些术语之前要么经常中英文混杂使用，要么中文译法不确定，我们根据多年的翻译和开发经验，在 GitHub 译法的基础上进行斟酌，整理了如下的术语表供大家使用参考。此外，“复刻”这个翻译应该是我们 LCTT 首倡的；而“议题”这个对 issue 的译法也比之前的一些其它译法更为精准；“仓库”一词还有存储库、版本库等译法，但是仓库一词似乎更加合适。

受让人 （ assignee ）

分配到某个议题的用户。

追溯 （ blame ）

Git 中的“追溯”功能描述对文件每行的最新修改，一般会显示修订、作者和时间。这很有用，例如，可以跟踪何时添加了功能，或者哪个提交导致了特定漏洞。

分支 （ branch ）

分支是仓库的平行版本。它包含在仓库中，但不影响主要或 master 分支，可让你自由工作而不中断“即时”版本。在执行所需的更改后，可以将分支合并回 master 分支以发布更改。

检出 （ checkout ）

你可以在命令行上使用 git checkout 创建新分支，将当前的工作分支更改为不同的分支，甚至使用 git checkout [branchname] [path to file]从不同的分支切换到不同版本的文件。“检出”操作会使用对象数据库中的树对象或 blob 更新工作树的全部或部分，以及更新索引和 HEAD（如果整个工作树指向新分支）。

优选 （ cherry-picking ）

从一系列更改（通常是提交）中选择一部分更改，并在不同的代码库上将它们记录为新的更改系列。在 Git 中，这通过 git cherry-pick 命令来执行，在另一个分支上解压缩现有提交引入的更改，并根据当前分支的提示将其记录为新提交。

清洁 （ clean ）

工作树在对应当前头部引用的版本时是清洁的。另请参阅“脏”。

克隆 （ clone ）

克隆是指存在于计算机上而非网站服务器其他位置的仓库副本，或者是复制的操作。在克隆时，可在首选编辑器中编辑文件，使用 Git 跟踪更改而无需保持在线。你克隆的仓库仍与远程版本连接，以便当你在线时将本地更改推送到远程，以保持同步。

行为准则 （ code of conduct ）

为如何参与社区制定标准的文档。

代码所有者 （ code owner ）

被指定为部分仓库代码所有者的个人。当有人打开对代码所有者拥有的代码进行更改的拉取请求（非草稿模式）时，会自动申请代码所有者审查。

协作者 （ collaborator ）

协作者是受仓库所有者邀请参与，对仓库拥有读取和写入权限的人。

提交 （ commit ）

提交或“修订”是对一个文件（或一组文件）的个别更改。在进行提交以保存工作时，Git 会创建唯一的 ID（也称为 "SHA" 或“哈希”），用于记录提交的特定更改以及提交者和提交时间。提交通常包含一条提交消息，其中简要说明所做的更改。

提交作者 （ commit author ）

进行提交的用户。

提交 ID （ commit ID ）

也称为 SHA。用于识别提交的 40 字符校验和的哈希。

提交消息 （ commit message ）

随附于提交的简短描述性文字，用于沟通提交引入的更改。

持续集成 （ continuous integration ）

也称为 CI。在个人对 GitHub 上配置的仓库提交更改后运行自动化构建和测试的过程。CI 是软件开发中一种帮助检测错误的常用最佳实践。

贡献指南 （ contribution guidelines ）

说明人们应如何参与项目的文档。

贡献 （ contributions ）

GitHub 上的特定活动。

贡献者 （ contributor ）

贡献者是指对仓库没有协作者权限但参与过项目，并且他们打开的拉取请求已合并到仓库的人员。

默认分支 （ default branch ）

仓库中的基本分支，除非你指定不同的分支，否则会自动对它完成所有拉取请求和代码提交。此分支通常称为 master。

游离的 HEAD （ detached HEAD ）

如果你操作的是游离的 HEAD，Git 将会警告你，这意味着 Git 不指向某个分支，并且你的任何提交都不会出现在提交历史记录中。例如，在检出并非任何特定分支最新提交的任意提交时，你操作的是“游离的 HEAD”。

差异 （ diff ）

差异是指两个提交之间的更改或保存的更改之间的区别，它将从视觉上描述文件自上次提交后添加或删除的内容。

脏 （ dirty ）

工作树如果包含尚未提交到当前分支的更改，将被视为“脏”。

快进 （ fast-forward ）

快进是一种特殊类型的合并，在其中你有修订以及“合并”另一个分支的更改作为现有分支的子系。在这种情况下，你无法进行新的合并提交，而只是更新此修订。这在远程仓库的远程跟踪分支中经常发生。

功能分支 （ feature branch ）

用于试验新功能或修复未正式使用的议题的分支。也称为主题分支。

围栏代码块 （ fenced code block ）

你可以在代码块前后使用三个反引号 `，通过 GitHub Flavored Markdown 创建缩进代码块。

获取 （ fetch ）

在使用 git fetch 时，你将从远程仓库添加更改到本地工作分支，而不提交它们。与 git pull 不同，提取可让你在更改提交到本地分支之前先进行审查。

跟进（用户） （ following (users) ）

获取关于另一个用户的贡献和活动的通知。

强制推送 （ force push ）

一种使用本地更改覆盖远程仓库的 Git 推送，不管是否冲突。

复刻 （ fork ）

复刻是其他用户仓库在你的帐户上的个人副本。复刻允许你自由更改项目而不影响原始上游仓库。你也可以在上游仓库中打开拉取请求，并使复刻同步最新的更改，因为两个仓库仍然互相连接。

gitfile

一种普通的 .git 文件，始终位于工作树的根部，指向 Git 目录，包含整个 Git 仓库及其元数据。你可以在命令行上使用 git rev-parse --git-dir 查看仓库（实际仓库）的此文件。

HEAD

当前分支。

挂钩 （ hook ）

在多个 Git 命令正常执行时，对可选脚本进行标注以允许开发者添加功能或检查。通常，挂钩允许预先验证和潜在中止命令，并且允许在操作完成后再发事后通知。

实例 （ instance ）

组织包含在其配置和控制的虚拟机中的 GitHub 私有副本。

议题 （ issue ）

议题是提议的与仓库相关的改进、任务或问题。（对于公共仓库）任何人都可创建议题，然后由仓库协作者调解。每个议题都包含自己的讨论线程。你也可以使用标签将议题归类并分配到某人。

密钥指纹 （ key fingerprint ）

用于识别较长公钥的简短字节系列。

关键词 （ keyword ）

用在拉取请求中时关闭议题的特定文字。

标签 （ label ）

议题或拉取请求的标记。仓库随附一系列默认标签，但用户也可创建自定义标签。

LFS

Git Large File Storage。一种开源 Git 扩展，用于对大文件进行版本控制。

许可证 （ license ）

一种可随附于项目的文档，告知们能够对你的源代码执行哪些操作，不能执行哪些操作。

行注释 （ line comment ）

拉取请求内特定代码行上的评论。

主干 （ master ）

默认开发分支。只要创建 Git 仓库，就会创建一个名为 master 的分支，并且它会变为活动的分支。大多数情况下，这包含本地开发，但纯属惯例，而非必需。

提及 （ mention ）

一种通过在用户名前加上 @ 符号来发送给用户的通知。GitHub 上组织中的用户也可成为可提及的团队一部分。

合并 （ merge ）

合并是从一个分支（在相同的仓库中或来自一个分叉）提取更改，然后将其应用到另一个分支。这通常是作为“拉取请求”（可视为请求合并）或通过命令行完成。如果没有冲突的更改，可通过 GitHub.com web 界面使用拉取请求完成合并，或始终通过命令行完成。

合并冲突 （ merge conflict ）

合并的分支之间发生的差异。当人们对同一文件的同一行进行不同的更改时，或者一个人编辑某文件而另一个人删除该文件时，就会发生合并冲突。必须解决合并冲突后才可合并分支。

合并请求 （ merge request ）

合并请求（MR）是 GitLab 上类似于 GitHub 上的拉取请求的概念。

里程碑 （ milestone ）

一种跟踪仓库中议题或拉取请求组进度的方式。

镜像 （ mirror ）

仓库的新副本。

非快进 （ non-fast-forward ）

当仓库的本地副本未与上游仓库同步时，你在推送本地更改之前需要提取上游更改。

通知 （ notification ）

web 或电子邮件（根据你的设置）传送的更新，提供你感兴趣的活动的相关信息。

外部协作者 （ outside collaborator ）

已被授予访问一个或多个组织的仓库但对组织没有其他访问权限的用户，且不属于组织的成员。

开源 （ open source ）

开源软件是可供任何人自由使用、修改和共享（以修改和未修改的形式）的软件。今天，“开源”的概念通常扩展到软件以外，代表一种协作原则，其中工作材料在线供任何人分叉、修改、讨论和参与。

源 （ origin ）

默认上游仓库。大多数项目至少有一个它们跟踪的上游项目。默认情况下，源用于该目的。

所有者 （ owner ）

对组织有完全管理权限的组织成员。

私有贡献 （ private contributions ）

对私有（与公共相对）仓库的贡献。

私有仓库 （ private repository ）

私有仓库仅对仓库所有者和所有者指定的协作者可见。

生产分支 （ production branch ）

包含可使用或部署到应用程序或站点的最终更改的分支。

个人资料 （ profile ）

显示 GitHub 上用户活动相关信息的页面。

受保护分支 （ protected branch ）

受保护分支在仓库管理员选择保护的分支上禁止多项 Git 功能。必要检查未通过或必需审查未批准，不能对它们执行强制推送、删除和更改合并，或者不能从 GitHub web 界面上传文件到其中。受保护分支通常是默认分支。

公共贡献 （ public contributions ）

对公共（与私有相对）仓库的贡献。

公共仓库 （ public repository ）

公共仓库可供任何人查看，包括不是 GitHub 用户的人员。

拉取 （ pull ）

拉取是指提取与合并更改。例如，如果有人编辑了你操作的远程文件，你要将这些更改拉取到本地副本，以使其保持最新。另请参阅“提取”。

拉取权限 （ pull access ）

读取权限的同义词。

拉取请求 （ pull request ）

拉取请求（PR）是提议更改用户提交的仓库，然后被仓库协作者接受或拒绝。像议题一样，每个拉取请求都有自己的论坛。

拉取请求审查 （ pull request review ）

拉取请求中协作者批准更改或在拉取请求合并之前申请进一步更改的评论。

推送 （ push ）

推送是指将提交的更改发送到 GitHub.com 上的远程仓库。例如，如果你在本地更改内容，便可推送这些更改，让其他人访问。

推送分支 （ push a branch ）

成功将分支推送到远程仓库后，使用本地分支中的更改来更新远程分支。在你“推送分支”时，Git 将会到远程仓库中搜索分支的头部引用，并验证它是分支本地头部引用的直系原型。在验证后，Git 将拉取所有对象（从本地头部引用可获取，而远程仓库中缺失）到远程对象数据库，然后更新远程头部引用。如果远程头部不是本地头部的原型，推送将会失败。

推送权限 （ push access ）

写入权限的同义词。

读取权限 （ read access ）

对仓库的权限级别，允许用户拉取或者读取仓库中的信息。所有公共仓库向所有 GitHub 用户授予读取权限。拉取权限的同义词。

自述文件 （ README ）

包含仓库中文件相关信息的文本文件，通常是仓库访问者看到的第一个文件。自述文件连同仓库许可证、参与指南以及行为准则，帮助你交流要求和管理项目的参与。

变基 （ rebase ）

将一系列更改从一个分支重新应用到不同的基本分支，并将该分支的头部重置为结果。

发布 （ release ）

GitHub 封装软件并向用户提供软件的方式。

远程 （ remote ）

这是托管于服务器（很可能是 GitHub.com）上的仓库或分支版本。远程版本可以连接到本地克隆，以使更改保持同步。

远程仓库 （ remote repository ）

用于跟踪同一个项目但储存在其他位置的仓库。

远程 URL （ remote URL ）

存储代码的位置：GitHub、其他用户分支甚至不同服务器 上的仓库。

副本 （ replica ）

为主要 GitHub Enterprise 实例提供冗余的 GitHub Enterprise 实例。

仓库 （ repository ）

仓库是 GitHub 最基本的元素，最容易被想象成项目的文件夹。一个仓库包含所有项目文件（包括文档），并且存储每个文件的修订历史记录。仓库可有多个协作者，也可以是公共仓库或私有仓库。

仓库维护员 （ repository maintainer ）

管理仓库的人员。此人可帮助对议题分类，以及使用标签和其他功能管理仓库的工作，也可负责更新自述文件和参与文件。

解决 （ resolve ）

手动修复自动合并失败的操作。

还原 （ revert ）

恢复 GitHub 上的拉取请求时，新拉取请求会自动打开，其中有一个提交用于从原始合并的拉取请求恢复合并提交。在 Git 中，你可以使用 git revert 恢复提交。

审查 （ review ）

审查允许对仓库具有访问权限的其他人评论拉取请求中提议的更改、审批更改或在拉取请求合并之前请求进一步更改。

服务挂钩 （ service hook ）

也称为“Web 挂钩”。Web 挂钩是一种通知方式，只要仓库或组织上发生特定操作，就会发送通知到外部 web 服务器。

压扁 （ squash ）

将多个提交合并为一个。也是 Git 命令。

暂存实例 （ staging instance ）

在修改应用到实际 GitHub Enterprise 实例之前测试修改的一种方式。

状态 （ status ）

拉取请求中的可视表现形式，表示你的提交符合你参与的仓库所设定的条件。

星标 （ star ）

仓库的书签或赞赏表示。星标是项目受欢迎程度排名的手动方式。

主题分支 （ topic branch ）

开发者用来识别开发概念行的常规 Git 分支。由于分支很容易并且便宜，因此往往适合拥有多个小分支，每个小分支包含定义明确的概念，或者渐进但相关的更改。也可称为“特征分支”。

上游 （ upstream ）

在谈论分支或分叉时，原始仓库的主要分支通常被称为“上游”，因为它是其他更改的主要来源。你操作的分支/分叉则称为“下游”。也称为“源”。

上游分支 （ upstream branch ）

合并到所述分支的默认分支（或所述分支变基到的分支）。它通过 branch.<name>.remote 和 branch.<name>.merge 配置。如果 A 的上游分支是源/B，有时我们会说“A 在跟踪源/B”。

查看 （ watch ）

你可以关注仓库或议题，以便在议题或拉取请求有更新时接收通知。

web 挂钩 （ webhooks ）

Web 挂钩可让你构建或设置订阅 GitHub.com 上特定事件的 GitHub 应用程序。Web 挂钩提供一种通知方式，只要仓库或组织中发生特定操作，就会发送通知到外部 web 服务器。也称为“服务挂钩”。

写入权限 （ write access ）

对仓库的权限级别，可让用户推送或写入更改到仓库。

使用子模块和子树来帮助你管理多个存储库中共有的子项目。

如果你参与了开源项目的开发，那么你很可能已经用了 Git 来管理你的源码。你可能遇到过有很多依赖和/或子项目的项目。你是如何管理它们的？

对于一个开源组织，要实现社区和产品的单一来源文档和依赖管理比较棘手。文档和项目往往会碎片化和变得冗余，这致使它们很难维护。

必要性

假设你想把单个项目作为一个存储库内的子项目，传统的方法是把该项目复制到父存储库中，但是，如果你想要在多个父项目中使用同一个子项目呢？如果把子项目复制到所有父项目中，当有更新时，你都要在每个父项目中做修改，这是不太可行的。这会导致父项目中的冗余和数据不一致，使更新和维护子项目变得很困难。

Git 子模块和子树

如果你可以用一条命令把一个项目放进另一个项目中，会怎样呢？如果你随时可以把一个项目作为子项目添加到任意数目的项目中，并可以同步更新修改呢？Git 提供了这类问题的解决方案：Git 子模块 submodule 和 Git 子树 subtree 。创建这些工具的目的是以更加模块化的水平来支持共用代码的开发工作流，旨在 Git 存储库 源码管理 source-code management （SCM）与它下面的子树之间架起一座桥梁。

生长在桑树上的樱桃树

下面是本文要详细介绍的概念的一个真实应用场景。如果你已经很熟悉树形结构，这个模型看起来是下面这样：

Git 子模块是什么？

Git 在它默认的包中提供了子模块，子模块可以把 Git 存储库嵌入到其他存储库中。确切地说，Git 子模块指向子树中的某次提交。下面是我 Docs-test GitHub 存储库中的 Git 子模块的样子：

文件夹@提交 Id 格式表明这个存储库是一个子模块，你可以直接点击文件夹进入该子树。名为 .gitmodules 的配置文件包含所有子模块存储库的详细信息。我的存储库的 .gitmodules 文件如下：

你可以用下面的命令在你的存储库中使用 Git 子模块：

克隆一个存储库并加载子模块

克隆一个含有子模块的存储库：

$ git clone --recursive <URL to Git repo>

如果你之前已经克隆了存储库，现在想加载它的子模块：

$ git submodule update --init

如果有嵌套的子模块：

$ git submodule update --init --recursive

下载子模块

串行地连续下载多个子模块是很枯燥的工作，所以 clone 和 submodule update 会支持 --jobs （或 -j）参数：

例如，想一次下载 8 个子模块，使用：

$ git submodule update --init --recursive -j 8
$ git clone --recursive --jobs 8 <URL to Git repo>

拉取子模块

在运行或构建父项目之前，你需要确保依赖的子项目都是最新的。

拉取子模块的所有修改：

$ git submodule update --remote

使用子模块创建存储库：

向一个父存储库添加子树：

$ git submodule add <URL to Git repo>

初始化一个已存在的 Git 子模块：

$ git submodule init

你也可以通过为 submodule update 命令添加 --update 参数在子模块中创建分支和追踪提交：

$ git submodule update --remote

更新子模块的提交

上面提到过，一个子模块就是一个指向子树中某次提交的链接。如果你想更新子模块的提交，不要担心。你不需要显式地指定最新的提交。你只需要使用通用的 submodule update 命令：

$ git submodule update

就像你平时创建父存储库和把父存储库推送到 GitHub 那样添加和提交就可以了。

从一个父存储库中删除一个子模块

仅仅手动删除一个子项目文件夹不会从父项目中移除这个子项目。想要删除名为 childmodule 的子模块，使用：

$ git rm -f childmodule

虽然 Git 子模块看起来很容易上手，但是对于初学者来说，有一定的使用门槛。

Git 子树是什么？

Git 子树 subtree ，是在 Git 1.7.11 引入的，让你可以把任何存储库的副本作为子目录嵌入另一个存储库中。它是 Git 项目可以注入和管理项目依赖的几种方法之一。它在常规的提交中保存了外部依赖信息。Git 子树提供了整洁的集成点，因此很容易复原它们。

如果你参考 GitHub 提供的子树教程来使用子树，那么无论你什么时候添加子树，在本地都不会看到 .gittrees 配置文件。这让我们很难分辨哪个是子树，因为它们看起来很像普通的文件夹，但是它们却是子树的副本。默认的 Git 包中不提供带 .gittrees 配置文件的 Git 子树版本，因此如果你想要带 .gittrees 配置文件的 git-subtree 命令，必须从 Git 源码存储库的 /contrib/subtree 文件夹 下载 git-subtree。

你可以像克隆其他常规的存储库那样克隆任何含有子树的存储库，但由于在父存储库中有整个子树的副本，因此克隆过程可能会持续很长时间。

你可以用下面的命令在你的存储库中使用 Git 子树。

向父存储库中添加一个子树

想要向父存储库中添加一个子树，首先你需要执行 remote add，之后执行 subtree add 命令：

$ git remote add remote-name <URL to Git repo>
$ git subtree add --prefix=folder/ remote-name <URL to Git repo> subtree-branchname

上面的命令会把整个子项目的提交历史合并到父存储库。

向子树推送修改以及从子树拉取修改

$ git subtree push-all

或者

$ git subtree pull-all

你应该使用哪个？

任何工具都有优缺点。下面是一些可能会帮助你决定哪种最适合你的特性：

• Git 子模块的存储库占用空间更小，因为它们只是指向子项目的某次提交的链接，而 Git 子树保存了整个子项目及其提交历史。
• Git 子模块需要在服务器中可访问，但子树是去中心化的。
• Git 子模块大量用于基于组件的开发，而 Git 子树多用于基于系统的开发。

Git 子树并不是 Git 子模块的直接可替代项。有明确的说明来指导我们该使用哪种。如果有一个归属于你的外部存储库，使用场景是向它回推代码，那么就使用 Git 子模块，因为推送代码更容易。如果你有第三方代码，且不会向它推送代码，那么使用 Git 子树，因为拉取代码更容易。

自己尝试使用 Git 子树和子模块，然后在评论中留下你的使用感想。

via: https://opensource.com/article/20/5/git-submodules-subtrees

作者：Manaswini Das 选题：lujun9972 译者：lxbwolf 校对：wxy

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