diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 89e1ba93..f145a29f 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -134,7 +134,7 @@ - [编写测试及控制执行](test/write-tests.md) - [单元测试和集成测试](test/unit-integration-test.md) - [断言 assertion](test/assertion.md) - - [用 Github Actions 进行持续集成](test/ci.md) + - [用 GitHub Actions 进行持续集成](test/ci.md) - [基准测试 benchmark](test/benchmark.md) - [Cargo 使用指南](cargo/intro.md) diff --git a/src/about-book.md b/src/about-book.md index a8107245..6dbcea60 100644 --- a/src/about-book.md +++ b/src/about-book.md @@ -11,7 +11,7 @@ Rust语言真的好：连续六年成为全世界最受欢迎的语言、没有G 如果看到这里，大家觉得这本书的介绍并没有吸引到你，不要立即放弃，强烈建议读一下[进入 Rust 编程世界](https://course.rs/into-rust.html)，那里会有不一样的精彩。 -> 本书完全开源，所有的文档内容都在 `Github` 上，至于里面还藏有什么秘密，大家点击右上角自行发现吧 ：） +> 本书完全开源，所有的文档内容都在 `GitHub` 上，至于里面还藏有什么秘密，大家点击右上角自行发现吧 ：） > > 小秘密一： 你们可能会好奇，这本书到底与其它 Rust 书籍有[哪些不同](https://github.com/sunface/rust-course#教程简介) @@ -26,7 +26,7 @@ Rust语言真的好：连续六年成为全世界最受欢迎的语言、没有G 同时社区还提供了一个优质的公众号： `studyrust`，里面的文章是由 [Rustt](https://rustt.org) 翻译组提供，搬运自国外优秀的 Rust 技术文章、学习资料、新闻资讯等。 -- 社区官网：[https://studyrust.org](https://studyrust.org)，正在建设中，暂时跳转到 Github 组织首页 +- 社区官网：[https://studyrust.org](https://studyrust.org)，正在建设中，暂时跳转到 GitHub 组织首页 - QQ交流群: 1009730433 - 微信公众号：`studyrust` diff --git a/src/advance/macro.md b/src/advance/macro.md index 1843a754..f8bc3bca 100644 --- a/src/advance/macro.md +++ b/src/advance/macro.md @@ -311,7 +311,7 @@ hello_macro 由于过程宏所在的包跟我们的项目紧密相连，因此将它放在项目之中。现在，问题又来了，该如何在项目的 `src/main.rs` 中引用 `hello_macro_derive` 包的内容？ -方法有两种，第一种是将 `hello_macro_derive` 发布到 `crates.io` 或 `github` 中，就像我们引用的其它依赖一样；另一种就是使用相对路径引入的本地化方式，修改 `hello_macro/Cargo.toml` 文件添加以下内容: +方法有两种，第一种是将 `hello_macro_derive` 发布到 `crates.io` 或 `GitHub` 中，就像我们引用的其它依赖一样；另一种就是使用相对路径引入的本地化方式，修改 `hello_macro/Cargo.toml` 文件添加以下内容: ```toml [dependencies] diff --git a/src/basic/crate-module/crate.md b/src/basic/crate-module/crate.md index 3f3815ce..8b1239f6 100644 --- a/src/basic/crate-module/crate.md +++ b/src/basic/crate-module/crate.md @@ -105,6 +105,6 @@ error: a bin target must be available for `cargo run` - 基准性能测试 `benchmark` 文件：`benches` 目录下 - 项目示例：`examples` 目录下 -这种目录结构基本上是 Rust 的标准目录结构，在 `github` 的大多数项目上，你都将看到它的身影。 +这种目录结构基本上是 Rust 的标准目录结构，在 `GitHub` 的大多数项目上，你都将看到它的身影。 理解了包的概念，我们再来看看构成包的基本单元：模块。 diff --git a/src/cargo/guide/cargo-toml-lock.md b/src/cargo/guide/cargo-toml-lock.md index e86bca9a..fba95add 100644 --- a/src/cargo/guide/cargo-toml-lock.md +++ b/src/cargo/guide/cargo-toml-lock.md @@ -9,7 +9,7 @@ ## 是否上传本地的 `Cargo.lock` -当本地开发时，`Cargo.lock` 自然是非常重要的，但是当你要把项目上传到 `Git` 时，例如 `Github`，那是否上传 `Cargo.lock` 就成了一个问题。 +当本地开发时，`Cargo.lock` 自然是非常重要的，但是当你要把项目上传到 `Git` 时，例如 `GitHub`，那是否上传 `Cargo.lock` 就成了一个问题。 关于是否上传，有如下经验准则: @@ -39,7 +39,7 @@ version = "0.1.0" regex = { git = "https://github.com/rust-lang/regex.git" } ``` -可以看到，只有一个依赖，且该依赖的来源是 `Github` 上一个特定的仓库。由于我们没有指定任何版本信息，`Cargo` 会自动拉取该依赖库的最新版本( `master` 或 `main` 分支上的最新 `commit` )。 +可以看到，只有一个依赖，且该依赖的来源是 `GitHub` 上一个特定的仓库。由于我们没有指定任何版本信息，`Cargo` 会自动拉取该依赖库的最新版本( `master` 或 `main` 分支上的最新 `commit` )。 这种使用方式，其实就错失了包管理工具的最大的优点：版本管理。例如你在今天构建使用了版本 `A`，然后过了一段时间后，由于依赖包的升级，新的构建却使用了大更新版本 `B`，结果因为版本不兼容，导致了构建失败。 diff --git a/src/cargo/guide/download-package.md b/src/cargo/guide/download-package.md index 651e1f4d..6a7afc37 100644 --- a/src/cargo/guide/download-package.md +++ b/src/cargo/guide/download-package.md @@ -1,13 +1,13 @@ # 下载并构建 Package -如果看中 `Github` 上的某个开源 Rust 项目，那下载并构建它将是非常简单的。 +如果看中 `GitHub` 上的某个开源 Rust 项目，那下载并构建它将是非常简单的。 ```shell $ git clone https://github.com/rust-lang/regex.git $ cd regex ``` -如上所示，直接从 `github` 上克隆下来想要的项目，然后使用 `cargo build` 进行构建即可： +如上所示，直接从 `GitHub` 上克隆下来想要的项目，然后使用 `cargo build` 进行构建即可： ```shell $ cargo build diff --git a/src/cargo/guide/tests-ci.md b/src/cargo/guide/tests-ci.md index 97dd25a4..cbc31ff6 100644 --- a/src/cargo/guide/tests-ci.md +++ b/src/cargo/guide/tests-ci.md @@ -27,9 +27,9 @@ test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out 在有了持续集成后，只要编写好相应的编译、测试、发布配置文件，那持续集成平台会自动帮助我们完成整个相关的流程，期间无需任何人介入，高效且可靠。 -#### Github Actions +#### GitHub Actions -关于如何使用 `Github Actions` 进行持续集成，在[之前的章节](https://course.rs/test/ci.html)已经有过详细的介绍，这里就不再赘述。 +关于如何使用 `GitHub Actions` 进行持续集成，在[之前的章节](https://course.rs/test/ci.html)已经有过详细的介绍，这里就不再赘述。 #### Travis CI diff --git a/src/cargo/reference/deps-overriding.md b/src/cargo/reference/deps-overriding.md index 77c19248..971e3eaf 100644 --- a/src/cargo/reference/deps-overriding.md +++ b/src/cargo/reference/deps-overriding.md @@ -108,7 +108,7 @@ uuid = { git = 'https://github.com/uuid-rs/uuid' } #### 间接使用 `patch` -现在假设项目 `A` 的依赖是 `B` 和 `uuid`，而 `B` 的依赖也是 `uuid`，此时我们可以让 `A` 和 `B` 都使用来自 `github` 的 `patch` 版本，配置如下: +现在假设项目 `A` 的依赖是 `B` 和 `uuid`，而 `B` 的依赖也是 `uuid`，此时我们可以让 `A` 和 `B` 都使用来自 `GitHub` 的 `patch` 版本，配置如下: ```toml [package] diff --git a/src/cargo/reference/manifest.md b/src/cargo/reference/manifest.md index 001cf90f..f1df2936 100644 --- a/src/cargo/reference/manifest.md +++ b/src/cargo/reference/manifest.md @@ -184,7 +184,7 @@ homepage = "https://serde.rs/" #### repository -设置项目的源代码仓库地址，例如 `github` 链接: +设置项目的源代码仓库地址，例如 `GitHub` 链接: ```toml [package] diff --git a/src/cargo/reference/publishing-on-crates.io.md b/src/cargo/reference/publishing-on-crates.io.md index d685357a..b4f36108 100644 --- a/src/cargo/reference/publishing-on-crates.io.md +++ b/src/cargo/reference/publishing-on-crates.io.md @@ -1,12 +1,12 @@ # 发布到 crates.io -如果你想要把自己的开源项目分享给全世界，那最好的办法自然是 github。但如果是 Rust 的库，那除了发布到 github 外，我们还可以将其发布到 [crates.io](https://crates.io) 上，然后其它用户就可以很简单的对其进行引用。 +如果你想要把自己的开源项目分享给全世界，那最好的办法自然是 GitHub。但如果是 Rust 的库，那除了发布到 GitHub 外，我们还可以将其发布到 [crates.io](https://crates.io) 上，然后其它用户就可以很简单的对其进行引用。 > 注意：发布包到 `crates.io` 后，特定的版本无法被覆盖，要发布就必须使用新的版本号，代码也无法被删除! ## 首次发布之前 -**首先，我们需要一个账号**：访问 crates.io 的[主页](https://crates.io)，然后在右上角使用 Github 账户登陆，接着访问你的[账户设置](https://crates.io/settings/profile)页面，进入到 API Tokens 标签页下，生成新的 Token，并使用该 Token 在终端中进行登录: +**首先，我们需要一个账号**：访问 crates.io 的[主页](https://crates.io)，然后在右上角使用 GitHub 账户登陆，接着访问你的[账户设置](https://crates.io/settings/profile)页面，进入到 API Tokens 标签页下，生成新的 Token，并使用该 Token 在终端中进行登录: ```shell $ cargo login abcdefghijklmnopqrstuvwxyz012345 @@ -123,12 +123,12 @@ $ cargo owner --add github:rust-lang:owners $ cargo owner --remove github:rust-lang:owners ``` -命令中使用的 ownerID 必须是 Github 用户名或 Team 名。 +命令中使用的 ownerID 必须是 GitHub 用户名或 Team 名。 一旦一个用户 `B` 通过 `--add` 被加入到 `owner` 列表中，他将拥有该包相关的所有权利。例如发布新版本、yank 一个版本，还能增加和移除 owner，包含添加 `B` 为 owner 的 `A` 都可以被移除！ 因此，我们必须严肃的指出：**不要将你不信任的人添加为 owner !** 免得哪天反目成仇后，他把你移除了 - , - -但是对于 Team 又有所不同，通过 `-add` 添加的 Github Team owner，只拥有受限的权利。它们可以发布或 yank 某个版本，但是他们**不能添加或移除** owner！总之，Team 除了可以很方便的管理所有者分组的同时，还能防止一些未知的恶意。 +但是对于 Team 又有所不同，通过 `-add` 添加的 GitHub Team owner，只拥有受限的权利。它们可以发布或 yank 某个版本，但是他们**不能添加或移除** owner！总之，Team 除了可以很方便的管理所有者分组的同时，还能防止一些未知的恶意。 如果大家在添加 team 时遇到问题，可以看看官方的[相关文档](https://doc.rust-lang.org/stable/cargo/reference/publishing.html#github-permissions)，由于绝大多数人都无需此功能，因此这里不再详细展开。 diff --git a/src/cargo/reference/specify-deps.md b/src/cargo/reference/specify-deps.md index 7123ad96..4ab2c54a 100644 --- a/src/cargo/reference/specify-deps.md +++ b/src/cargo/reference/specify-deps.md @@ -1,6 +1,6 @@ # 指定依赖项 -我们的项目可以引用在 `crates.io` 或 `github` 上的依赖包，也可以引用存放在本地文件系统中的依赖包。 +我们的项目可以引用在 `crates.io` 或 `GitHub` 上的依赖包，也可以引用存放在本地文件系统中的依赖包。 大家可能会想，直接从前两个引用即可，为何还提供了本地方式？可以设想下，如果你要有一个正处于开发中的包，然后需要在本地的另一个项目中引用测试，那是将该包先传到网上，然后再引用简单，还是直接从本地路径的方式引用简单呢？答案显然不言而喻。 @@ -83,7 +83,7 @@ time = "0.1.12" >= 1.2, < 1.5 ``` -需要注意，以上的版本号规则仅仅针对 `crate.io` 和基于它搭建的注册服务(例如科大服务源) ，其它注册服务(例如 github )有自己相应的规则。 +需要注意，以上的版本号规则仅仅针对 `crate.io` 和基于它搭建的注册服务(例如科大服务源) ，其它注册服务(例如 GitHub )有自己相应的规则。 ## 从其它注册服务引入依赖包 diff --git a/src/github.md b/src/github.md index 15657f3f..c27f9530 100644 --- a/src/github.md +++ b/src/github.md @@ -1 +1 @@ -# Github +# GitHub diff --git a/src/into-rust.md b/src/into-rust.md index 900d931d..4771ba59 100644 --- a/src/into-rust.md +++ b/src/into-rust.md @@ -130,7 +130,7 @@ Rust 语言表达能力更强，性能更高。同时线程安全方面 Rust 也 - Google 除了在安卓系统的部分模块中使用 Rust 外，还在它最新的操作系统 Fuchsia 中重度使用 Rust - Facebook 使用 Rust 来增强自己的网页端、移动端和 API 服务的性能，同时还写了 Hack 编程语言的虚拟机 - Microsoft 使用 Rust 为 Azure 平台提供一些组件，其中包括 IoT 的核心服务 -- Github 和 npmjs.com，使用 Rust 提供高达每天 13 亿次的 npm 包下载 +- GitHub 和 npmjs.com，使用 Rust 提供高达每天 13 亿次的 npm 包下载 - Rust 目前已经成为全世界区块链平台的首选开发语言 - TiDB，国内最有名的开源分布式数据库 diff --git a/src/test/ci.md b/src/test/ci.md index 5efcb443..738af6fe 100644 --- a/src/test/ci.md +++ b/src/test/ci.md @@ -1,6 +1,6 @@ -# 用 Github Actions 进行持续集成 +# 用 GitHub Actions 进行持续集成 -[Github Actions](https://github.com/features/actions) 是官方于 2018 年推出的持续集成服务，它非常强大，本文将手把手带领大家学习如何使用 `Github Actions` 对 Rust 项目进行持续集成。 +[GitHub Actions](https://github.com/features/actions) 是官方于 2018 年推出的持续集成服务，它非常强大，本文将手把手带领大家学习如何使用 `GitHub Actions` 对 Rust 项目进行持续集成。 持续集成是软件开发中异常重要的一环，大家应该都听说过 `Jenkins`，它就是一个拥有悠久历史的持续集成工具。简单来说，持续集成会定期拉取同一个项目中所有成员的相关代码，对其进行自动化构建。 @@ -8,11 +8,11 @@ 在有了持续集成后，只要编写好相应的编译、测试、发布配置文件，那持续集成平台会自动帮助我们完成整个相关的流程，期间无需任何人介入，高效且可靠。 -## Github Actions +## GitHub Actions -而本文的主角正是这样的持续集成平台，它由 Github 官方提供，并且跟 github 进行了深度的整合，其中 `actions` 代表了代码拉取、测试运行、登陆远程服务器、发布到第三方服务等操作行为。 +而本文的主角正是这样的持续集成平台，它由 GitHub 官方提供，并且跟 GitHub 进行了深度的整合，其中 `actions` 代表了代码拉取、测试运行、登陆远程服务器、发布到第三方服务等操作行为。 -最妙的是 Github 发现这些 `actions` 其实在很多项目中都是类似的，意味着 `actions` 完全可以被多个项目共享使用，而不是每个项目都从零开发自己的 `actions`。 +最妙的是 GitHub 发现这些 `actions` 其实在很多项目中都是类似的，意味着 `actions` 完全可以被多个项目共享使用，而不是每个项目都从零开发自己的 `actions`。 若你需要某个 `action`，不必自己写复杂的脚本，直接引用他人写好的 `action` 即可，整个持续集成过程，就变成了多个 `action` 的组合，这就是` GitHub Actions` 最厉害的地方。 @@ -20,8 +20,8 @@ 既然 `action` 这么强大，我们就可以将自己的 `action` 分享给他人，也可以引用他人分享的 `action`，有以下几种方式： -1. 将你的 `action` 放在 github 上的公共仓库中，这样其它开发者就可以引用，例如 [github-profile-summary-cards](https://github.com/vn7n24fzkq/github-profile-summary-cards) 就提供了相应的 `action`，可以生成 github 用户统计信息，然后嵌入到你的个人主页中，具体效果[见这里](https://github.com/sunface) -2. Github 提供了一个[官方市场](https://github.com/marketplace?type=actions)，里面收集了许多质量不错的 `actions`，并支持在线搜索 +1. 将你的 `action` 放在 GitHub 上的公共仓库中，这样其它开发者就可以引用，例如 [github-profile-summary-cards](https://github.com/vn7n24fzkq/github-profile-summary-cards) 就提供了相应的 `action`，可以生成 GitHub 用户统计信息，然后嵌入到你的个人主页中，具体效果[见这里](https://github.com/sunface) +2. GitHub 提供了一个[官方市场](https://github.com/marketplace?type=actions)，里面收集了许多质量不错的 `actions`，并支持在线搜索 3. [awesome-actions](https://github.com/sdras/awesome-actions)，由三方开发者收集并整理的 actions 4. [starter workflows](https://github.com/actions/starter-workflows)，由官方提供的工作流( workflow )模版 @@ -39,18 +39,18 @@ actions/setup-node@f099707 # 指向一个 commit ## Actions 基础 -在了解了何为 Github Actions 后，再来通过一个基本的例子来学习下它的基本概念，注意，由于篇幅有限，我们只会讲解最常用的部分，如果想要完整的学习，请移步[这里](https://docs.github.com/en/actions)。 +在了解了何为 GitHub Actions 后，再来通过一个基本的例子来学习下它的基本概念，注意，由于篇幅有限，我们只会讲解最常用的部分，如果想要完整的学习，请移步[这里](https://docs.github.com/en/actions)。 #### 创建 action demo -首先，为了演示，我们需要创建一个公开的 github 仓库 `rust-action`，然后在仓库主页的导航栏中点击 `Actions` ，你会看到如下页面 : +首先，为了演示，我们需要创建一个公开的 GitHub 仓库 `rust-action`，然后在仓库主页的导航栏中点击 `Actions` ，你会看到如下页面 : 接着点击 `set up a workflow yourself ->` ，你将看到系统为你自动创建的一个工作流 workflow ，在 `rust-action/.github/workflows/main.yml` 文件中包含以下内容: ```yml -# 下面是一个基础的工作流，你可以基于它来编写自己的 Github Actions +# 下面是一个基础的工作流，你可以基于它来编写自己的 GitHub Actions name: CI # 控制工作流何时运行 @@ -113,23 +113,23 @@ jobs: -至此，我们已经初步掌握 `Github Actions` 的用法，现在来看看一些基本的概念。 +至此，我们已经初步掌握 `GitHub Actions` 的用法，现在来看看一些基本的概念。 #### 基本概念 -- **Github Actions**，每个项目都拥有一个 `Actions` ，可以包含多个工作流 +- **GitHub Actions**，每个项目都拥有一个 `Actions` ，可以包含多个工作流 - **workflow 工作流**，描述了一次持续集成的过程 - **job 作业**，一个工作流可以包含多个作业，因为一次持续集成本身就由多个不同的部分组成 - **step 步骤**，每个作业由多个步骤组成，按照顺序一步一步完成 - **action 动作**，每个步骤可以包含多个动作，例如上例中的 `Run a multi-line script` 步骤就包含了两个动作 -可以看出，每一个概念都是相互包含的关系，前者包含了后者，层层相扣，正因为这些精心设计的对象才有了强大的 `Github Actions`。 +可以看出，每一个概念都是相互包含的关系，前者包含了后者，层层相扣，正因为这些精心设计的对象才有了强大的 `GitHub Actions`。 #### on `on` 可以设定事件用于触发工作流的运行： -1. 一个或多个 Github 事件，例如 `push` 一个 `commit`、创建一个 `issue`、提交一次 `pr` 等等，详细的事件列表参见[这里](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows) +1. 一个或多个 GitHub 事件，例如 `push` 一个 `commit`、创建一个 `issue`、提交一次 `pr` 等等，详细的事件列表参见[这里](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows) 2. 预定的时间，例如每天零点零分触发，详情见[这里](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule) @@ -138,7 +138,7 @@ on: schedule: -cron:'0 0 * * *' ``` -3. 外部事件触发，例如你可以通过 `REST API` 向 Github 发送请求去触发，具体请查阅[官方文档](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch) +3. 外部事件触发，例如你可以通过 `REST API` 向 GitHub 发送请求去触发，具体请查阅[官方文档](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#repository_dispatch) #### jobs @@ -159,9 +159,9 @@ jobs: #### runs-on -指定作业的运行环境，运行器 `runner` 分为两种：`GitHub-hosted runner` 和 `self-hosted runner`，后者是使用自己的机器来运行作业，但是需要 Github 能进行访问并给予相应的机器权限，感兴趣的同学可以看看[这里](https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job#choosing-self-hosted-runners)。 +指定作业的运行环境，运行器 `runner` 分为两种：`GitHub-hosted runner` 和 `self-hosted runner`，后者是使用自己的机器来运行作业，但是需要 GitHub 能进行访问并给予相应的机器权限，感兴趣的同学可以看看[这里](https://docs.github.com/en/actions/using-jobs/choosing-the-runner-for-a-job#choosing-self-hosted-runners)。 -而对于前者，Github 提供了以下的运行环境： +而对于前者，GitHub 提供了以下的运行环境： @@ -221,18 +221,18 @@ jobs: 如果有多个 `env` 存在，会使用就近那个。 -至此，`Github Actions` 的常用内容大家已经基本了解，下面来看一个实用的示例。 +至此，`GitHub Actions` 的常用内容大家已经基本了解，下面来看一个实用的示例。 -## 真实示例：生成 Github 统计卡片 +## 真实示例：生成 GitHub 统计卡片 -相信大家看过不少用户都定制了自己的个性化 Github 首页，这个是通过在个人名下创建一个同名的仓库来实现的，该仓库中的 `Readme.md` 的内容会自动展示在你的个人首页中，例如 `Sunface` 的[个人首页](https://github.com/sunface) 和内容所在的[仓库](https://github.com/sunface/sunface)。 +相信大家看过不少用户都定制了自己的个性化 GitHub 首页，这个是通过在个人名下创建一个同名的仓库来实现的，该仓库中的 `Readme.md` 的内容会自动展示在你的个人首页中，例如 `Sunface` 的[个人首页](https://github.com/sunface) 和内容所在的[仓库](https://github.com/sunface/sunface)。 -大家可能会好奇上面链接中的 Github 统计卡片如何生成，其实有两种办法: +大家可能会好奇上面链接中的 GitHub 统计卡片如何生成，其实有两种办法: - 使用 [github-readme-stats](https://github.com/anuraghazra/github-readme-stats) -- 使用 `Github Actions` 来引用其它人提供的 `action` 生成对应的卡片，再嵌入进来， `Sunface` 的个人首页就是这么做的 +- 使用 `GitHub Actions` 来引用其它人提供的 `action` 生成对应的卡片，再嵌入进来， `Sunface` 的个人首页就是这么做的 -第一种的优点就是非常简单，缺点是样式不太容易统一，不能对齐对于强迫症来说实在难受 :( 而后者的优点是规规整整的卡片，缺点就是使用起来更加复杂，而我们正好借此来看看真实的 `Github Actions` 长什么样。 +第一种的优点就是非常简单，缺点是样式不太容易统一，不能对齐对于强迫症来说实在难受 :( 而后者的优点是规规整整的卡片，缺点就是使用起来更加复杂，而我们正好借此来看看真实的 `GitHub Actions` 长什么样。 首先，在你的同名项目下创建 `.github/workflows/profile-summary-cards.yml` 文件，然后填入以下内容: diff --git a/src/test/unit-integration-test.md b/src/test/unit-integration-test.md index 3d7e6636..b526de88 100644 --- a/src/test/unit-integration-test.md +++ b/src/test/unit-integration-test.md @@ -198,4 +198,4 @@ Rust 提供了单元测试和集成测试两种方式来帮助我们组织测试 - 单元测试的模块和待测试的代码在同一个文件中，且可以很方便地对私有函数进行测试 - 集成测试文件放在项目根目录下的 `tests` 目录中，由于该目录下每个文件都是一个包，我们必须要引入待测试的代码到当前包的作用域中，才能进行测试，正因为此，集成测试只能对声明为 `pub` 的 API 进行测试 -下个章节，我们再来看看该如何使用 `Github Actions` 对 Rust 项目进行持续集成。 +下个章节，我们再来看看该如何使用 `GitHub Actions` 对 Rust 项目进行持续集成。 diff --git a/内容变更记录.md b/内容变更记录.md index 866c0e73..6c5c3b6a 100644 --- a/内容变更记录.md +++ b/内容变更记录.md @@ -18,7 +18,7 @@ ## 2022-03-28 - 新增章节：[双单向链表](https://course.rs/too-many-lists/advanced-lists/double-singly.html) -- 优化样式：增加目录中的区域性标题、修改 github 图标和说明，通过 js 增加访问者统计 +- 优化样式：增加目录中的区域性标题、修改 GitHub 图标和说明，通过 js 增加访问者统计 - 新增创作感悟 ## 2022-03-27