mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-04 22:00:34 +08:00
Hacker
GitHub
commit
fcd3a358f3
262
published/20190221 Testing Bash with BATS.md
Normal file
262
published/20190221 Testing Bash with BATS.md
Normal file
@ -0,0 +1,262 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (stevenzdg988)
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-13194-1.html)
|
||||
[#]: subject: (Testing Bash with BATS)
|
||||
[#]: via: (https://opensource.com/article/19/2/testing-bash-bats)
|
||||
[#]: author: (Darin London https://opensource.com/users/dmlond)
|
||||
|
||||
利用 BATS 测试 Bash 脚本和库
|
||||
======
|
||||
|
||||
> Bash 自动测试系统可以使 Bash 代码也通过 Java、Ruby 和 Python 开发人员所使用的同类测试过程。
|
||||
|
||||
|
||||
|
||||
用 Java、Ruby 和 Python 等语言编写应用程序的软件开发人员拥有复杂的库，可以帮助他们随着时间的推移保持软件的完整性。他们可以创建测试，以在结构化环境中通过执行一系列动作来运行应用程序，以确保其软件所有的方面均按预期工作。
|
||||
|
||||
当这些测试在持续集成（CI）系统中自动进行时，它们的功能就更加强大了，每次推送到源代码库都会触发测试，并且在测试失败时会立即通知开发人员。这种快速反馈提高了开发人员对其应用程序功能完整性的信心。
|
||||
|
||||
<ruby>Bash 自动测试系统<rt>Bash Automated Testing System</rt></ruby>（[BATS][1]）使编写 Bash 脚本和库的开发人员能够将 Java、Ruby、Python 和其他开发人员所使用的相同惯例应用于其 Bash 代码中。
|
||||
|
||||
### 安装 BATS
|
||||
|
||||
BATS GitHub 页面包含了安装指令。有两个 BATS 辅助库提供更强大的断言或允许覆写 BATS 使用的 Test Anything Protocol（[TAP][2]）输出格式。这些库可以安装在一个标准位置，并被所有的脚本引用。更方便的做法是，将 BATS 及其辅助库的完整版本包含在 Git 仓库中，用于要测试的每组脚本或库。这可以通过 [git 子模块][3] 系统来完成。
|
||||
|
||||
以下命令会将 BATS 及其辅助库安装到 Git 知识库中的 `test` 目录中。
|
||||
|
||||
```
|
||||
git submodule init
|
||||
git submodule add https://github.com/sstephenson/bats test/libs/bats
|
||||
git submodule add https://github.com/ztombol/bats-assert test/libs/bats-assert
|
||||
git submodule add https://github.com/ztombol/bats-support test/libs/bats-support
|
||||
git add .
|
||||
git commit -m 'installed bats'
|
||||
```
|
||||
|
||||
要克隆 Git 仓库并同时安装其子模块，请在 `git clone` 时使用
|
||||
`--recurse-submodules` 标记。
|
||||
|
||||
每个 BATS 测试脚本必须由 `bats` 可执行文件执行。如果你将 BATS 安装到源代码仓库的 `test/libs` 目录中，则可以使用以下命令调用测试：
|
||||
|
||||
```
|
||||
./test/libs/bats/bin/bats <测试脚本的路径>
|
||||
```
|
||||
|
||||
或者，将以下内容添加到每个 BATS 测试脚本的开头：
|
||||
|
||||
```
|
||||
#!/usr/bin/env ./test/libs/bats/bin/bats
|
||||
load 'libs/bats-support/load'
|
||||
load 'libs/bats-assert/load'
|
||||
```
|
||||
|
||||
并且执行命令 `chmod +x <测试脚本的路径>`。 这将 a、使它们可与安装在 `./test/libs/bats` 中的 BATS 一同执行，并且 b、包含这些辅助库。BATS 测试脚本通常存储在 `test` 目录中，并以要测试的脚本命名，扩展名为 `.bats`。例如，一个测试 `bin/build` 的 BATS 脚本应称为 `test/build.bats`。
|
||||
|
||||
你还可以通过向 BATS 传递正则表达式来运行一整套 BATS 测试文件，例如 `./test/lib/bats/bin/bats test/*.bats`。
|
||||
|
||||
### 为 BATS 覆盖率而组织库和脚本
|
||||
|
||||
Bash 脚本和库必须以一种有效地方式将其内部工作原理暴露给 BATS 进行组织。通常，在调用或执行时库函数和运行诸多命令的 Shell 脚本不适合进行有效的 BATS 测试。
|
||||
|
||||
例如，[build.sh][4] 是许多人都会编写的典型脚本。本质上是一大堆代码。有些人甚至可能将这堆代码放入库中的函数中。但是，在 BATS 测试中运行一大堆代码，并在单独的测试用例中覆盖它可能遇到的所有故障类型是不可能的。测试这堆代码并有足够的覆盖率的唯一方法就是把它分解成许多小的、可重用的、最重要的是可独立测试的函数。
|
||||
|
||||
向库添加更多的函数很简单。额外的好处是其中一些函数本身可以变得出奇的有用。将库函数分解为许多较小的函数后，你可以在 BATS 测试中<ruby>援引<rt>source</er></ruby>这些库，并像测试任何其他命令一样运行这些函数。
|
||||
|
||||
Bash 脚本也必须分解为多个函数，执行脚本时，脚本的主要部分应调用这些函数。此外，还有一个非常有用的技巧，可以让你更容易地用 BATS 测试 Bash 脚本：将脚本主要部分中执行的所有代码都移到一个函数中，称为 `run_main`。然后，将以下内容添加到脚本的末尾：
|
||||
|
||||
```
|
||||
if [[ "${BASH_SOURCE[0]}" == "${0}" ]]
|
||||
then
|
||||
run_main
|
||||
fi
|
||||
```
|
||||
|
||||
这段额外的代码做了一些特别的事情。它使脚本在作为脚本执行时与使用<ruby>援引<rt>source</er></ruby>进入环境时的行为有所不同。通过援引并测试单个函数，这个技巧使得脚本的测试方式和库的测试方式变得一样。例如，[这是重构的 build.sh，以获得更好的 BATS 可测试性][5]。
|
||||
|
||||
### 编写和运行测试
|
||||
|
||||
如上所述，BATS 是一个 TAP 兼容的测试框架，其语法和输出对于使用过其他 TAP 兼容测试套件（例如 JUnit、RSpec 或 Jest）的用户来说将是熟悉的。它的测试被组织成单个测试脚本。测试脚本被组织成一个或多个描述性 `@test` 块中，它们描述了被测试应用程序的单元。每个 `@test` 块将运行一系列命令，这些命令准备测试环境、运行要测试的命令，并对被测试命令的退出和输出进行断言。许多断言函数是通过 `bats`、`bats-assert` 和 `bats-support` 库导入的，这些库在 BATS 测试脚本的开头加载到环境中。下面是一个典型的 BATS 测试块：
|
||||
|
||||
```
|
||||
@test "requires CI_COMMIT_REF_SLUG environment variable" {
|
||||
unset CI_COMMIT_REF_SLUG
|
||||
assert_empty "${CI_COMMIT_REF_SLUG}"
|
||||
run some_command
|
||||
assert_failure
|
||||
assert_output --partial "CI_COMMIT_REF_SLUG"
|
||||
}
|
||||
```
|
||||
|
||||
如果 BATS 脚本包含 `setup`（安装）和/或 `teardown`（拆卸） 函数，则 BATS 将在每个测试块运行之前和之后自动执行它们。这样就可以创建环境变量、测试文件以及执行一个或所有测试所需的其他操作，然后在每次测试运行后将其拆卸。[Build.bats][6] 是对我们新格式化的 `build.sh` 脚本的完整 BATS 测试。（此测试中的 `mock_docker` 命令将在以下关于模拟/打标的部分中进行说明。）
|
||||
|
||||
当测试脚本运行时，BATS 使用 `exec`（执行）来将每个 `@test` 块作为单独的子进程运行。这样就可以在一个 `@test` 中导出环境变量甚至函数，而不会影响其他 `@test` 或污染你当前的 Shell 会话。测试运行的输出是一种标准格式，可以被人理解，并且可以由 TAP 使用端以编程方式进行解析或操作。下面是 `CI_COMMIT_REF_SLUG` 测试块失败时的输出示例：
|
||||
|
||||
```
|
||||
✗ requires CI_COMMIT_REF_SLUG environment variable
|
||||
(from function `assert_output' in file test/libs/bats-assert/src/assert.bash, line 231,
|
||||
in test file test/ci_deploy.bats, line 26)
|
||||
`assert_output --partial "CI_COMMIT_REF_SLUG"' failed
|
||||
|
||||
-- output does not contain substring --
|
||||
substring (1 lines):
|
||||
CI_COMMIT_REF_SLUG
|
||||
output (3 lines):
|
||||
./bin/deploy.sh: join_string_by: command not found
|
||||
oc error
|
||||
Could not login
|
||||
--
|
||||
|
||||
** Did not delete , as test failed **
|
||||
|
||||
1 test, 1 failure
|
||||
```
|
||||
|
||||
下面是成功测试的输出：
|
||||
|
||||
```
|
||||
✓ requires CI_COMMIT_REF_SLUG environment variable
|
||||
```
|
||||
|
||||
### 辅助库
|
||||
|
||||
像任何 Shell 脚本或库一样，BATS 测试脚本可以包括辅助库，以在测试之间共享通用代码或增强其性能。这些辅助库，例如 `bats-assert` 和 `bats-support` 甚至可以使用 BATS 进行测试。
|
||||
|
||||
库可以和 BATS 脚本放在同一个测试目录下，如果测试目录下的文件数量过多，也可以放在 `test/libs` 目录下。BATS 提供了 `load` 函数，该函数接受一个相对于要测试的脚本的 Bash 文件的路径（例如，在我们的示例中的 `test`），并援引该文件。文件必须以后缀 `.bash` 结尾，但是传递给 `load` 函数的文件路径不能包含后缀。`build.bats` 加载 `bats-assert` 和 `bats-support` 库、一个小型 [helpers.bash][7] 库以及 `docker_mock.bash` 库（如下所述），以下代码位于测试脚本的开头，解释器魔力行下方：
|
||||
|
||||
```
|
||||
load 'libs/bats-support/load'
|
||||
load 'libs/bats-assert/load'
|
||||
load 'helpers'
|
||||
load 'docker_mock'
|
||||
```
|
||||
|
||||
### 打标测试输入和模拟外部调用
|
||||
|
||||
大多数 Bash 脚本和库运行时都会执行函数和/或可执行文件。通常，它们被编程为基于这些函数或可执行文件的输出状态或输出（`stdout`、`stderr`）以特定方式运行。为了正确地测试这些脚本，通常需要制作这些命令的伪版本，这些命令被设计成在特定测试过程中以特定方式运行，称为“<ruby>打标<rt>stubbing</rt></ruby>”。可能还需要监视正在测试的程序，以确保其调用了特定命令，或者使用特定参数调用了特定命令，此过程称为“<ruby>模拟<rt>mocking</rt></ruby>”。有关更多信息，请查看在 Ruby RSpec 中 [有关模拟和打标的讨论][8]，它适用于任何测试系统。
|
||||
|
||||
Bash shell 提供了一些技巧，可以在你的 BATS 测试脚本中使用这些技巧进行模拟和打标。所有这些都需要使用带有 `-f` 标志的 Bash `export` 命令来导出一个覆盖了原始函数或可执行文件的函数。必须在测试程序执行之前完成此操作。下面是重写可执行命令 `cat` 的简单示例：
|
||||
|
||||
```
|
||||
function cat() { echo "THIS WOULD CAT ${*}" }
|
||||
export -f cat
|
||||
```
|
||||
|
||||
此方法以相同的方式覆盖了函数。如果一个测试需要覆盖要测试的脚本或库中的函数，则在对函数进行打标或模拟之前，必须先声明已测试脚本或库，这一点很重要。否则，在声明脚本时，打标/模拟将被原函数替代。另外，在运行即将进行的测试命令之前确认打标/模拟。下面是`build.bats` 的示例，该示例模拟 `build.sh` 中描述的`raise` 函数，以确保登录函数会引发特定的错误消息：
|
||||
|
||||
```
|
||||
@test ".login raises on oc error" {
|
||||
source ${profile_script}
|
||||
function raise() { echo "${1} raised"; }
|
||||
export -f raise
|
||||
run login
|
||||
assert_failure
|
||||
assert_output -p "Could not login raised"
|
||||
}
|
||||
```
|
||||
|
||||
一般情况下，没有必要在测试后复原打标/模拟的函数，因为 `export`（输出）仅在当前 `@test` 块的 `exec`（执行）期间影响当前子进程。但是，可以模拟/打标 BATS `assert` 函数在内部使用的命令（例如 `cat`、`sed` 等）是可能的。在运行这些断言命令之前，必须对这些模拟/打标函数进行 `unset`（复原），否则它们将无法正常工作。下面是 `build.bats` 中的一个示例，该示例模拟 `sed`，运行 `build_deployable` 函数并在运行任何断言之前复原 `sed`：
|
||||
|
||||
```
|
||||
@test ".build_deployable prints information, runs docker build on a modified Dockerfile.production and publish_image when its not a dry_run" {
|
||||
local expected_dockerfile='Dockerfile.production'
|
||||
local application='application'
|
||||
local environment='environment'
|
||||
local expected_original_base_image="${application}"
|
||||
local expected_candidate_image="${application}-candidate:${environment}"
|
||||
local expected_deployable_image="${application}:${environment}"
|
||||
source ${profile_script}
|
||||
mock_docker build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t "${expected_deployable_image}" -
|
||||
function publish_image() { echo "publish_image ${*}"; }
|
||||
export -f publish_image
|
||||
function sed() {
|
||||
echo "sed ${*}" >&2;
|
||||
echo "FROM application-candidate:environment";
|
||||
}
|
||||
export -f sed
|
||||
run build_deployable "${application}" "${environment}"
|
||||
assert_success
|
||||
unset sed
|
||||
assert_output --regexp "sed.*${expected_dockerfile}"
|
||||
assert_output -p "Building ${expected_original_base_image} deployable ${expected_deployable_image} FROM ${expected_candidate_image}"
|
||||
assert_output -p "FROM ${expected_candidate_image} piped"
|
||||
assert_output -p "build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t ${expected_deployable_image} -"
|
||||
assert_output -p "publish_image ${expected_deployable_image}"
|
||||
}
|
||||
```
|
||||
|
||||
有的时候相同的命令，例如 `foo`，将在被测试的同一函数中使用不同的参数多次调用。这些情况需要创建一组函数：
|
||||
|
||||
* `mock_foo`：将期望的参数作为输入，并将其持久化到 TMP 文件中
|
||||
* `foo`：命令的模拟版本，该命令使用持久化的预期参数列表处理每个调用。必须使用 `export -f` 将其导出。
|
||||
* `cleanup_foo`：删除 TMP 文件，用于拆卸函数。这可以进行测试以确保在删除之前成功完成 `@test` 块。
|
||||
|
||||
由于此功能通常在不同的测试中重复使用，因此创建一个可以像其他库一样加载的辅助库会变得有意义。
|
||||
|
||||
[docker_mock.bash][9] 是一个很棒的例子。它被加载到 `build.bats` 中，并在任何测试调用 Docker 可执行文件的函数的测试块中使用。使用 `docker_mock` 典型的测试块如下所示：
|
||||
|
||||
```
|
||||
@test ".publish_image fails if docker push fails" {
|
||||
setup_publish
|
||||
local expected_image="image"
|
||||
local expected_publishable_image="${CI_REGISTRY_IMAGE}/${expected_image}"
|
||||
source ${profile_script}
|
||||
mock_docker tag "${expected_image}" "${expected_publishable_image}"
|
||||
mock_docker push "${expected_publishable_image}" and_fail
|
||||
run publish_image "${expected_image}"
|
||||
assert_failure
|
||||
assert_output -p "tagging ${expected_image} as ${expected_publishable_image}"
|
||||
assert_output -p "tag ${expected_image} ${expected_publishable_image}"
|
||||
assert_output -p "pushing image to gitlab registry"
|
||||
assert_output -p "push ${expected_publishable_image}"
|
||||
}
|
||||
```
|
||||
|
||||
该测试建立了一个使用不同的参数两次调用 Docker 的预期。在对Docker 的第二次调用失败时，它会运行测试命令，然后测试退出状态和对 Docker 调用的预期。
|
||||
|
||||
一方面 BATS 利用 `mock_docker.bash` 引入 `${BATS_TMPDIR}` 环境变量，BATS 在测试开始的位置对其进行了设置，以允许测试和辅助程序在标准位置创建和销毁 TMP 文件。如果测试失败，`mock_docker.bash` 库不会删除其持久化的模拟文件，但会打印出其所在位置，以便可以查看和删除它。你可能需要定期从该目录中清除旧的模拟文件。
|
||||
|
||||
关于模拟/打标的一个注意事项：`build.bats` 测试有意识地违反了关于测试声明的规定：[不要模拟没有拥有的！][10] 该规定要求调用开发人员没有编写代码的测试命令，例如 `docker`、`cat`、`sed` 等，应封装在自己的库中，应在使用它们脚本的测试中对其进行模拟。然后应该在不模拟外部命令的情况下测试封装库。
|
||||
|
||||
这是一个很好的建议，而忽略它是有代价的。如果 Docker CLI API 发生变化，则测试脚本不会检测到此变化，从而导致错误内容直到经过测试的 `build.sh` 脚本在使用新版本 Docker 的生产环境中运行后才显示出来。测试开发人员必须确定要严格遵守此标准的程度，但是他们应该了解其所涉及的权衡。
|
||||
|
||||
### 总结
|
||||
|
||||
在任何软件开发项目中引入测试制度，都会在以下两方面产生权衡： a、增加开发和维护代码及测试所需的时间和组织，b、增加开发人员在对应用程序整个生命周期中完整性的信心。测试制度可能不适用于所有脚本和库。
|
||||
|
||||
通常，满足以下一个或多个条件的脚本和库才可以使用 BATS 测试：
|
||||
|
||||
* 值得存储在源代码管理中
|
||||
* 用于关键流程中，并依靠它们长期稳定运行
|
||||
* 需要定期对其进行修改以添加/删除/修改其功能
|
||||
* 可以被其他人使用
|
||||
|
||||
一旦决定将测试规则应用于一个或多个 Bash 脚本或库，BATS 就提供其他软件开发环境中可用的全面测试功能。
|
||||
|
||||
致谢：感谢 [Darrin Mann][11] 向我引荐了 BATS 测试。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/2/testing-bash-bats
|
||||
|
||||
作者：[Darin London][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[stevenzdg988](https://github.com/stevenzdg988)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dmlond
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://github.com/sstephenson/bats
|
||||
[2]: http://testanything.org/
|
||||
[3]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
|
||||
[4]: https://github.com/dmlond/how_to_bats/blob/preBats/build.sh
|
||||
[5]: https://github.com/dmlond/how_to_bats/blob/master/bin/build.sh
|
||||
[6]: https://github.com/dmlond/how_to_bats/blob/master/test/build.bats
|
||||
[7]: https://github.com/dmlond/how_to_bats/blob/master/test/helpers.bash
|
||||
[8]: https://www.codewithjason.com/rspec-mocks-stubs-plain-english/
|
||||
[9]: https://github.com/dmlond/how_to_bats/blob/master/test/docker_mock.bash
|
||||
[10]: https://github.com/testdouble/contributing-tests/wiki/Don't-mock-what-you-don't-own
|
||||
[11]: https://github.com/dmann
|
||||
@ -3,32 +3,32 @@
|
||||
[#]: author: (Abhishek Prakash https://itsfoss.com/author/abhishek/)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-13195-1.html)
|
||||
|
||||
你现在可以在 Ubuntu 和基于 Debian 的 Linux 发行版上安装官方 Evernote 客户端了
|
||||
在 Linux 上安装官方 Evernote 客户端
|
||||
======
|
||||
|
||||
|
||||
|
||||
[Evernote][1] 是一款流行的笔记应用。它在推出时是一个革命性的产品。从那时起，已经有好几个这样的应用，可以将网络剪报、笔记等保存为笔记本格式。
|
||||
|
||||
多年来，Evernote 的桌面客户端一直没有在 Linux 上使用。前段时间 Evernote 承诺推出 Linux 应用，其测试版终于可以在基于 Ubuntu 的发行版上使用了。
|
||||
多年来，Evernote 一直没有在 Linux 上使用的桌面客户端。前段时间 Evernote 承诺推出 Linux 应用，其测试版终于可以在基于 Ubuntu 的发行版上使用了。
|
||||
|
||||
非 FOSS 警报！
|
||||
|
||||
Evernote Linux 客户端不是开源的。之所以在这里介绍它，是因为该应用是在 Linux 上提供的，我们也会不定期地介绍 Linux 用户常用的非 foss 应用。这对普通桌面 Linux 用户有帮助。
|
||||
> 非 FOSS 警报！
|
||||
>
|
||||
> Evernote Linux 客户端不是开源的。之所以在这里介绍它，是因为该应用是在 Linux 上提供的，我们也会不定期地介绍 Linux 用户常用的非 FOSS 应用。这对普通桌面 Linux 用户有帮助。
|
||||
|
||||
### 在 Ubuntu 和基于 Debian 的 Linux 发行版上安装 Evernote
|
||||
|
||||
进入下面这个 Evernote 的网站页面：
|
||||
|
||||
[Evernote Linux Beta Program][2]
|
||||
进入这个 Evernote 的[网站页面][2]。
|
||||
|
||||
向下滚动一点，接受“早期测试计划”的条款和条件。你会看到一个“立即安装”的按钮出现在屏幕上。点击它来下载 DEB 文件。
|
||||
|
||||
![][3]
|
||||
|
||||
要[从 DEB 文件安装应用][4]，请双击它。它应该会打开软件中心，并给你选择安装它。
|
||||
要 [从 DEB 文件安装应用][4]，请双击它。它应该会打开软件中心，并给你选择安装它。
|
||||
|
||||
![][5]
|
||||
|
||||
@ -50,11 +50,11 @@ Evernote Linux 客户端不是开源的。之所以在这里介绍它，是因
|
||||
|
||||
由于软件处于测试版，因此这里或那里会有些问题。
|
||||
|
||||
如上图所示，Evernote Linux 客户端检测到 [Ubuntu 中的深色模式][9]并自动切换到深色主题。然而，当我把系统主题改为浅色或标准主题时，它并没有立即改变应用主题。这些变化是在我重启 Evernote 应用后才生效的。
|
||||
如上图所示，Evernote Linux 客户端检测到 [Ubuntu 中的深色模式][9] 并自动切换到深色主题。然而，当我把系统主题改为浅色或标准主题时，它并没有立即改变应用主题。这些变化是在我重启 Evernote 应用后才生效的。
|
||||
|
||||
另一个问题是关于关闭应用。如果你点击 X 按钮关闭 Evernote，程序会进入后台而不是退出。
|
||||
另一个问题是关于关闭应用。如果你点击 “X” 按钮关闭 Evernote，程序会进入后台而不是退出。
|
||||
|
||||
有一个应用指示器，似乎可以启动最小化的 Evernote，就像 [Linux 上的 Skype][10]。不幸的是，事实并非如此。它打开了便笺，让你快速输入笔记。
|
||||
有一个似乎可以启动最小化的 Evernote 的应用指示器，就像 [Linux 上的 Skype][10]。不幸的是，事实并非如此。它打开了便笺，让你快速输入笔记。
|
||||
|
||||
这为你提供了另一个 [Linux 上的笔记应用][11]，但它也带来了一个问题。这里没有退出 Evernote 的选项。它只用于打开快速记事应用。
|
||||
|
||||
@ -62,7 +62,7 @@ Evernote Linux 客户端不是开源的。之所以在这里介绍它，是因
|
||||
|
||||
那么，如何退出 Evernote 应用呢？为此，再次打开 Evernote 应用。如果它在后台运行，在菜单中搜索它，并启动它，就像你重新打开它一样。
|
||||
|
||||
当 Evernote 应用在前台运行时，点击 File->Quit 退出 Evernote。
|
||||
当 Evernote 应用在前台运行时，点击 “文件->退出” 来退出 Evernote。
|
||||
|
||||
![][13]
|
||||
|
||||
@ -81,7 +81,7 @@ via: https://itsfoss.com/install-evernote-ubuntu/
|
||||
作者：[Abhishek Prakash][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -0,0 +1,63 @@
|
||||
[#]: subject: (Test cases and open source license enforcement)
|
||||
[#]: via: (https://opensource.com/article/21/3/test-cases-open-source-licenses)
|
||||
[#]: author: (Richard Fontana https://opensource.com/users/fontana)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
Test cases and open source license enforcement
|
||||
======
|
||||
If you're trying to enforce open source licenses, test case litigation
|
||||
is not the right way to do it.
|
||||
![A gavel.][1]
|
||||
|
||||
A test case is a lawsuit brought primarily to achieve a policy outcome by securing a judicial ruling that reverses settled law or clarifies some disputed legal question. Bringing a test case typically involves carefully planning out where, when, and whom to sue and which legal arguments to advance in order to maximize the chances of winning the desired result. In the United States, we often see test case strategies used by public interest organizations to effect legal change that cannot practically be attained through other governmental means.
|
||||
|
||||
But a test case strategy can be used by either side of a policy dispute. Even if a test case is successful, the real policy goal may continue to be elusive, given the limitations of case-specific court judgments, which may be met with administrative obstruction or legislative nullification. Test case litigation can also fail, sometimes disastrously—in the worst case, from the test litigant's perspective, the court might issue a ruling that is the direct opposite of what was sought, as happened in [_Plessy v. Ferguson_][2].
|
||||
|
||||
It may be hard to imagine a test case centered around interpretation of a software license. While licenses are necessarily based on underlying legal rules, typical software licenses are private transactions with terms that are negotiated by the parties or are form agreements unique to the licensor. Normally, a dispute over interpretation of some term in a software license would not be expected to implicate the sort of broadly applicable policy issues that are the usual focus of test case litigation.
|
||||
|
||||
But open source is quite different in this respect. Most open source software is governed by a small set of de facto standard licenses, used without modification or customization across a wide range of projects. Relatedly, open source licenses have an importance to project communities that extends beyond mere licensing terms. They are "[constitutions of communities][3]," an expression of the collaborative and ethical norms of those communities. For these reasons, [open source licenses function as shared resources][4]. This characteristic makes a license-enforcement test case conceivable.
|
||||
|
||||
Whether there actually has ever been an open source license test case is unclear. Litigation over open source licenses has been quite uncommon (though it may be [increasing][5]). Most open source license compliance matters are resolved through voluntary efforts by the licensee, or through community discussion or amicable negotiation with licensors, without resort to the courts. Open source license-enforcement litigation has mostly involved the GPL or another copyleft license in the GNU license family. The fairly small number of litigated GPL enforcement cases brought by community-oriented organizations—Harald Welte's [GPL-violations.org][6] cases, the [Free Software Foundation's suit against Cisco][7], the [BusyBox cases][8]—largely involved factually straightforward "no source or offer" violations. The [copyright profiteering lawsuits][9] brought by Patrick McHardy are clearly not calculated to lead to judicial rulings on questions of GPL interpretation.
|
||||
|
||||
One notable GPL enforcement suit that arguably has some of the characteristics of a test case is Christoph Hellwig's [now-concluded case against VMware in Germany][10], which was funded by the Software Freedom Conservancy. The Hellwig case was apparently the first GPL enforcement lawsuit to raise as a central issue the scope of derivative works under GPLv2, a core copyleft and GPL interpretation policy issue and a policy topic that has been debated in technical and legal communities for decades. Hellwig and Conservancy may have hoped that a victory on the merits would have a far-reaching regulatory impact on activities long-criticized by many GPL supporters, particularly the practice of distributing proprietary Linux kernel modules using GPL-licensed "shim" layers. Then again, Conservancy itself was careful to downplay the notion that the Hellwig case was intended as "[the great test case of combined/derivative works.][11]" And the facts in the Hellwig case, involving a proprietary VMware kernel and GPL-licensed kernel modules, were fairly unusual in comparison to typical GPL-compliance scenarios involving Linux.
|
||||
|
||||
Some developers and lawyers may be predisposed to view open source test cases positively. But this ignores the downsides of test case litigation in the open source context, which are a direct consequence of open source licenses being shared resources. Litigation, whether based on test cases or otherwise, is a poor means of pursuing open source license compliance. You might assume that if open source licenses are shared resources, litigation resulting in judicial rulings would be beneficial by providing increased legal certainty over the limited set of licenses in wide use. But this rests on an unrealistically rosy view of litigation and its impact. Given that open source licenses are, for the most part, a small set of widely reused license texts, actions taken by a few individuals can adversely affect an entire community sharing the same license.
|
||||
|
||||
A court decision by a judge in a dispute between two parties arising out of a unique set of facts is one means by which that impact can occur. The judge, in all likelihood, will not be well informed about open source or technology in general. The judge's rulings will be shaped by the arguments of lawyers for the parties who have incentives to advance legal arguments that may be in conflict with the values and norms of communities relying on the license at issue. The litigants themselves, including the litigant seeking to enforce the license, may not share those values and norms. The capacity of the court to look beyond the arguments presented by the litigants is very limited, and authentic representatives of the project communities using the license will have no meaningful opportunity to give their perspective.
|
||||
|
||||
If, as is therefore likely, license-enforcement litigation produces a bad decision with a large community impact, the license-using community may then be stuck with that decision with few good options to remedy the situation. In many cases, there will be no easy path for a project to migrate to a different license, including a new version of the litigated license that attempts to correct against the court decision. There may be no license steward, or the license may not facilitate downstream upgradeability. Even if there is a license steward, there is generally strong social pressure in free and open source software (FOSS) to avoid license revision.
|
||||
|
||||
Test case litigation would not be immune to these kinds of problems; their drawbacks are amplified in the open source setting. For one thing, a test case might be brought by supporters of a license interpretation that is disfavored in the relevant license-using community—let's call this a "bad" test case litigant. Even if we suppose that the test case litigant's policy objectives reflect a real consensus in the license-using community—a "good" test case litigant—the test case strategy could backfire. The case might result in a ruling that is the opposite of what the test case litigant sought. Or the test case litigant might win on the facts, but in the process, the court might issue one or more rulings framed differently from what the test case litigant hoped for, perhaps having unexpected negative consequences for license interpretation or imposing undesirable new burdens on license compliance. The court might also dispose of the case in some procedural manner that could have a negative impact on the license-using community.
|
||||
|
||||
A more fundamental problem is that we really cannot know whether a given test case litigant is "good" or "bad" because of the complex and diverse nature of views on license interpretation across open source project communities. For example, an organization that is generally trusted in the community may be tempted to use test case litigation to promote highly restrictive or literalist interpretations of a license that are out of step with prevailing community views or practices.
|
||||
|
||||
Rather than pursuing open source license enforcement policy through test case litigation, we should first fully explore the use of community-based governance approaches to promote appropriate license interpretations and compliance expectations. This would be especially helpful in signaling that restrictive or illiberal license interpretations, advanced in litigation by parties motivated by private gain, have no basis of support in the larger community that shares that license text. For example, we can document and publicize license interpretations that are widely accepted in the community, expanding on work already done by some license stewards. We can also promote more liberal and modern interpretations of widely used licenses that were drafted in a different technological context, while still upholding their underlying policies, with the aim of making compliance clearer, fairer, and easier. Finally, we should consider adopting more frequent upgrade cycles for popular licenses using public and transparent license-revision processes.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/3/test-cases-open-source-licenses
|
||||
|
||||
作者：[Richard Fontana][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/fontana
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/law_legal_gavel_court.jpg?itok=tc27pzjI (A gavel.)
|
||||
[2]: https://www.oyez.org/cases/1850-1900/163us537
|
||||
[3]: https://meshedinsights.com/2015/12/21/faq-license/
|
||||
[4]: https://opensource.com/law/16/11/licenses-are-shared-resources
|
||||
[5]: https://opensource.com/article/19/2/top-foss-legal-developments
|
||||
[6]: http://gpl-violations.org/
|
||||
[7]: https://en.wikipedia.org/wiki/Free_Software_Foundation,_Inc._v._Cisco_Systems,_Inc.
|
||||
[8]: https://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits
|
||||
[9]: https://opensource.com/article/17/8/patrick-mchardy-and-copyright-profiteering
|
||||
[10]: https://sfconservancy.org/news/2019/apr/02/vmware-no-appeal/
|
||||
[11]: https://sfconservancy.org/copyleft-compliance/vmware-lawsuit-faq.html
|
||||
@ -1,138 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (stevenzdg988)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (6 best practices for managing Git repos)
|
||||
[#]: via: (https://opensource.com/article/20/7/git-repos-best-practices)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
6 best practices for managing Git repos
|
||||
======
|
||||
Resist the urge to add things in Git that will make it harder to manage;
|
||||
here's what to do instead.
|
||||
![Working from home at a laptop][1]
|
||||
|
||||
Having access to source code makes it possible to analyze the security and safety of applications. But if nobody actually looks at the code, the issues won’t get caught, and even when people are actively looking at code, there’s usually quite a lot to look at. Fortunately, GitHub has an active security team, and recently, they [revealed a Trojan that had been committed into several Git repositories][2], having snuck past even the repo owners. While we can’t control how other people manage their own repositories, we can learn from their mistakes. To that end, this article reviews some of the best practices when it comes to adding files to your own repositories.
|
||||
|
||||
### Know your repo
|
||||
|
||||
![Git repository terminal][3]
|
||||
|
||||
This is arguably Rule Zero for a secure Git repository. As a project maintainer, whether you started it yourself or you’ve adopted it from someone else, it’s your job to know the contents of your own repository. You might not have a memorized list of every file in your codebase, but you need to know the basic components of what you’re managing. Should a stray file appear after a few dozen merges, you’ll be able to spot it easily because you won’t know what it’s for, and you’ll need to inspect it to refresh your memory. When that happens, review the file and make sure you understand exactly why it’s necessary.
|
||||
|
||||
### Ban binary blobs
|
||||
|
||||
![Git binary check command in terminal][4]
|
||||
|
||||
Git is meant for text, whether it’s C or Python or Java written in plain text, or JSON, YAML, XML, Markdown, HTML, or something similar. Git isn’t ideal for binary files.
|
||||
|
||||
It’s the difference between this:
|
||||
|
||||
|
||||
```
|
||||
$ cat hello.txt
|
||||
This is plain text.
|
||||
It's readable by humans and machines alike.
|
||||
Git knows how to version this.
|
||||
|
||||
$ git diff hello.txt
|
||||
diff --git a/hello.txt b/hello.txt
|
||||
index f227cc3..0d85b44 100644
|
||||
\--- a/hello.txt
|
||||
+++ b/hello.txt
|
||||
@@ -1,2 +1,3 @@
|
||||
This is plain text.
|
||||
+It's readable by humans and machines alike.
|
||||
Git knows how to version this.
|
||||
```
|
||||
|
||||
and this:
|
||||
|
||||
|
||||
```
|
||||
$ git diff pixel.png
|
||||
diff --git a/pixel.png b/pixel.png
|
||||
index 563235a..7aab7bc 100644
|
||||
Binary files a/pixel.png and b/pixel.png differ
|
||||
|
||||
$ cat pixel.png
|
||||
<EFBFBD>PNG
|
||||
▒
|
||||
IHDR7n<EFBFBD>$gAMA<4D><41>
|
||||
<20>abKGD݊<44>tIME<4D>
|
||||
|
||||
-2R<32><52>
|
||||
IDA<EFBFBD>c`<60>!<21>3%tEXtdate:create2020-06-11T11:45:04+12:00<30><30>r.%tEXtdate:modify2020-06-11T11:45:04+12:00<30><30>ʒIEND<4E>B`<60>
|
||||
```
|
||||
|
||||
The data in a binary file can’t be parsed in the same way plain text can be parsed, so if anything is changed in a binary file, the whole thing must be rewritten. The only difference between one version and the other is everything, which adds up quickly.
|
||||
|
||||
Worse still, binary data can’t be reasonably audited by you, the Git repository maintainer. That’s a violation of Rule Zero: know what’s in your repository.
|
||||
|
||||
In addition to the usual [POSIX][5] tools, you can detect binaries using `git diff`. When you try to diff a binary file using the `--numstat` option, Git returns a null result:
|
||||
|
||||
|
||||
```
|
||||
$ git diff --numstat /dev/null pixel.png | tee
|
||||
\- - /dev/null => pixel.png
|
||||
$ git diff --numstat /dev/null file.txt | tee
|
||||
5788 0 /dev/null => list.txt
|
||||
```
|
||||
|
||||
If you’re considering committing binary blobs to your repository, stop and think about it first. If it’s binary, it was generated by something. Is there a good reason not to generate them at build time instead of committing them to your repo? Should you decide it does make sense to commit binary data, make sure you identify, in a README file or similar, where the binary files are, why they’re binary, and what the protocol is for updating them. Updates must be performed sparingly, because, for every change you commit to a binary blob, the storage space for that blob effectively doubles.
|
||||
|
||||
### Keep third-party libraries third-party
|
||||
|
||||
Third-party libraries are no exception to this rule. While it’s one of the many benefits of open source that you can freely re-use and re-distribute code you didn’t write, there are many good reasons not to house a third-party library in your own repository. First of all, you can’t exactly vouch for a third party, unless you’ve reviewed all of its code (and future merges) yourself. Secondly, when you copy third party libraries into your Git repo, it splinters focus away from the true upstream source. Someone confident in the library is technically only confident in the master copy of the library, not in a copy lying around in a random repo. If you need to lock into a specific version of a library, either provide developers with a reasonable URL the release your project needs or else use [Git Submodule][6].
|
||||
|
||||
### Resist a blind git add
|
||||
|
||||
![Git manual add command in terminal][7]
|
||||
|
||||
If your project is compiled, resist the urge to use `git add .` (where `.` is either the current directory or the path to a specific folder) as an easy way to add anything and everything new. This is especially important if you’re not manually compiling your project, but are using an IDE to manage your project for you. It can be extremely difficult to track what’s gotten added to your repository when an IDE manages your project, so it’s important to only add what you’ve actually written and not any new object that pops up in your project folder.
|
||||
|
||||
If you do use `git add .`, review what’s in staging before you push. If you see an unfamiliar object in your project folder when you do a `git status`, find out where it came from and why it’s still in your project directory after you’ve run a `make clean` or equivalent command. It’s a rare build artifact that won’t regenerate during compilation, so think twice before committing it.
|
||||
|
||||
### Use Git ignore
|
||||
|
||||
![Git ignore command in terminal][8]
|
||||
|
||||
Many of the conveniences built for programmers are also very noisy. The typical project directory for any project, programming, or artistic or otherwise, is littered with hidden files, metadata, and leftover artifacts. You can try to ignore these objects, but the more noise there is in your `git status`, the more likely you are to miss something.
|
||||
|
||||
You can Git filter out this noise for you by maintaining a good gitignore file. Because that’s a common requirement for anyone using Git, there are a few starter gitignore files available. [Github.com/github/gitignore][9] offers several purpose-built gitignore files you can download and place into your own project, and [Gitlab.com][10] integrated gitignore templates into the repo creation workflow several years ago. Use these to help you build a reasonable gitignore policy for your project, and stick to it.
|
||||
|
||||
### Review merge requests
|
||||
|
||||
![Git merge request][11]
|
||||
|
||||
When you get a merge or pull request or a patch file through email, don’t just test it to make sure it works. It’s your job to read new code coming into your codebase and to understand how it produces the result it does. If you disagree with the implementation, or worse, you don’t comprehend the implementation, send a message back to the person submitting it and ask for clarification. It’s not a social faux pas to question code looking to become a permanent fixture in your repository, but it’s a breach of your social contract with your users to not know what you merge into the code they’ll be using.
|
||||
|
||||
### Git responsible
|
||||
|
||||
Good software security in open source is a community effort. Don’t encourage poor Git practices in your repositories, and don’t overlook a security threat in repositories you clone. Git is powerful, but it’s still just a computer program, so be the human in the equation and keep everyone safe.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/git-repos-best-practices
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[stevenzdg988](https://github.com/stevenzdg988)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/wfh_work_home_laptop_work.png?itok=VFwToeMy (Working from home at a laptop)
|
||||
[2]: https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain/
|
||||
[3]: https://opensource.com/sites/default/files/uploads/git_repo.png (Git repository )
|
||||
[4]: https://opensource.com/sites/default/files/uploads/git-binary-check.jpg (Git binary check)
|
||||
[5]: https://opensource.com/article/19/7/what-posix-richard-stallman-explains
|
||||
[6]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
|
||||
[7]: https://opensource.com/sites/default/files/uploads/git-cola-manual-add.jpg (Git manual add)
|
||||
[8]: https://opensource.com/sites/default/files/uploads/git-ignore.jpg (Git ignore)
|
||||
[9]: https://github.com/github/gitignore
|
||||
[10]: https://about.gitlab.com/releases/2016/05/22/gitlab-8-8-released
|
||||
[11]: https://opensource.com/sites/default/files/uploads/git_merge_request.png (Git merge request)
|
||||
@ -0,0 +1,248 @@
|
||||
[#]: subject: (Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact)
|
||||
[#]: via: (https://www.linux.com/news/review-of-four-hyperledger-libraries-aries-quilt-ursa-and-transact/)
|
||||
[#]: author: (Dan Brown https://training.linuxfoundation.org/announcements/review-of-four-hyperledger-libraries-aries-quilt-ursa-and-transact/)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact
|
||||
======
|
||||
|
||||
_By Matt Zand_
|
||||
|
||||
## **Recap**
|
||||
|
||||
In our two previous articles, first we covered “[Review of Five popular Hyperledger DLTs- Fabric, Besu, Sawtooth, Iroha and Indy][1]” where we discussed the following five Hyperledger Distributed Ledger Technologies (DLTs):
|
||||
|
||||
1. Hyperledger Indy
|
||||
2. Hyperledger Fabric
|
||||
3. Hyperledger Iroha
|
||||
4. Hyperledger Sawtooth
|
||||
5. Hyperledger Besu
|
||||
|
||||
|
||||
|
||||
Then, we moved on to our second article ([Review of three Hyperledger Tools- Caliper, Cello and Avalon][2]) where we surveyed the following three Hyperledger t ools:
|
||||
|
||||
1. Hyperledger Caliper
|
||||
2. Hyperledger Cello
|
||||
3. Hyperledger Avalon
|
||||
|
||||
|
||||
|
||||
So in this follow-up article, we review four (as listed below) Hyperledger libraries that work very well with other Hyperledger DLTs. As of this writing, all of these libraries are at the incubation stage except for Hyperledger Aries, which has [graduated][3] to active.
|
||||
|
||||
1. Hyperledger Aries
|
||||
2. Hyperledger Quilt
|
||||
3. Hyperledger Ursa
|
||||
4. Hyperledger Transact
|
||||
|
||||
|
||||
|
||||
**Hyperledger Aries**
|
||||
|
||||
Identity has been adopted by the industry as one of the most promising use cases of DLTs. Solutions and initiatives around creating, storing, and transmitting verifiable digital credentials will result in a reusable, shared, interoperable tool kit. In response to such growing demand, Hyperledger has come up with three projects (Hyperledger Indy, Hyperledger Iroha and Hyperledger Aries) that are specifically focused on identity management.
|
||||
|
||||
Hyperledger Aries is infrastructure for blockchain-rooted, peer-to-peer interactions. It includes a shared cryptographic wallet (the secure storage tech, not a UI) for blockchain clients as well as a communications protocol for allowing off-ledger interactions between those clients. This project consumes the cryptographic support provided by Hyperledger Ursa to provide secure secret management and decentralized key management functionality.
|
||||
|
||||
According to Hyperledger Aries’ documentation, Aries includes the following features:
|
||||
|
||||
* An encrypted messaging system for off-ledger interactions using multiple transport protocols between clients.
|
||||
* A blockchain interface layer that is also called as a resolver. It is used for creating and signing blockchain transactions.
|
||||
* A cryptographic wallet to enable secure storage of cryptographic secrets and other information that is used for building blockchain clients.
|
||||
* An implementation of ZKP-capable W3C verifiable credentials with the help of the ZKP primitives that are found in Hyperledger Ursa.
|
||||
* A mechanism to build API-like use cases and higher-level protocols based on secure messaging functionality.
|
||||
* An implementation of the specifications of the Decentralized Key Management System (DKMS) that are being currently incubated in Hyperledger Indy.
|
||||
* Initially, the generic interface of Hyperledger Aries will support the Hyperledger Indy resolver. But the interface is flexible in the sense that anyone can build a pluggable method using DID method resolvers such as Ethereum and Hyperledger Fabric, or any other DID method resolver they wish to use. These resolvers would support the resolving of transactions and other data on other ledgers.
|
||||
* Hyperledger Aries will additionally provide the functionality and features outside the scope of the Hyperledger Indy ledger to be fully planned and supported. Owing to these capabilities, the community can now build core message families to facilitate interoperable interactions using a wide range of use cases that involve blockchain-based identity.
|
||||
|
||||
|
||||
|
||||
For more detailed discussion on its implementation, visit the link provided in the References section.
|
||||
|
||||
**Hyperledger Quilt**
|
||||
|
||||
The widespread adoption of blockchain technology by global businesses has coincided with the emergence of tons of isolated and disconnected networks or ledgers. While users can easily conduct transactions within their own network or ledger, they experience technical difficultly (and in some cases impracticality) for doing transactions with parties residing on different networks or ledgers. At best, the process of cross-ledger (or cross-network) transactions is slow, expensive, or manual. However, with the advent and adoption of Interledger Protocol (ILP), money and other forms of value can be routed, packetized, and delivered over ledgers and payment networks.
|
||||
|
||||
Hyperledger Quilt is a tool for interoperability between ledger systems and is written in Java by implementing the ILP for atomic swaps. While the Interledger is a protocol for making transactions across ledgers, ILP is a payment protocol designed to transfer value across non-distributed and distributed ledgers. The standards and specifications of Interledger protocol are governed by the open-source community under the World Wide Web Consortium umbrella. Quilt is an enterprise-grade implementation of the ILP, and provides libraries and reference implementations for the core Interledger components used for payment networks. With the launch of Quilt, the JavaScript (Interledger.js) implementation of Interledger was maintained by the JS Foundation.
|
||||
|
||||
According to the Quilt documentation, as a result of ILP implementation, Quilt offers the following features:
|
||||
|
||||
* A framework to design higher-level use-case specific protocols.
|
||||
* A set of rules to enable interoperability with basic escrow semantics.
|
||||
* A standard for data packet format and a ledger-dependent independent address format to enable connectors to route payments.
|
||||
|
||||
|
||||
|
||||
For more detailed discussion on its implementation, visit the link provided in the References section.
|
||||
|
||||
**Hyperledger Ursa**
|
||||
|
||||
Hyperledger Ursa is a shared cryptographic library that enables people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library is an opt-in repository for Hyperledger projects (and, potentially others) to place and use crypto.
|
||||
|
||||
Inside Project Ursa, a complete library of modular signatures and symmetric-key primitives is at the disposal of developers to swap in and out different cryptographic schemes through configuration and without having to modify their code. On top its base library, Ursa also includes newer cryptography, including pairing-based, threshold, and aggregate signatures. Furthermore, the zero-knowledge primitives including SNARKs are also supported by Ursa.
|
||||
|
||||
According to the Ursa’s documentation, Ursa offers the following benefits:
|
||||
|
||||
* Preventing duplication of solving similar security requirements across different blockchain
|
||||
* Simplifying the security audits of cryptographic operations since the code is consolidated into a single location. This reduces maintenance efforts of these libraries while improving the security footprint for developers with beginner knowledge of distributed ledger projects.
|
||||
* Reviewing all cryptographic codes in a single place will reduce the likelihood of dangerous security bugs.
|
||||
* Boosting cross-platform interoperability when multiple platforms, which require cryptographic verification, are using the same security protocols on both platforms.
|
||||
* Enhancing the architecture via modularity of common components will pave the way for future modular distributed ledger technology platforms using common components.
|
||||
* Accelerating the time to market for new projects as long as an existing security paradigm can be plugged-in without a project needing to build it themselves.
|
||||
|
||||
|
||||
|
||||
For more detailed discussion on its implementation, visit the link provided in the References section.
|
||||
|
||||
**Hyperledger Transact**
|
||||
|
||||
Hyperledger Transact, in a nutshell, makes writing distributed ledger software easier by providing a shared software library that handles the execution of smart contracts, including all aspects of scheduling, transaction dispatch, and state management. Utilizing Transact, smart contracts can be executed irrespective of DLTs being used. Specifically, Transact achieves that by offering an extensible approach to implementing new smart contract languages called “smart contract engines.” As such, each smart contract engine implements a virtual machine or interpreter that processes smart contracts.
|
||||
|
||||
At its core, Transact is solely a transaction processing system for state transitions. That is, s tate data is normally stored in a key-value or an SQL database. Considering an initial state and a transaction, Transact executes the transaction to produce a new state. These state transitions are deemed “pure” because only the initial state and the transaction are used as input. (In contrast to other systems such as Ethereum where state and block information are mixed to produce the new state). Therefore, Transact is agnostic about DLT framework features other than transaction execution and state.
|
||||
|
||||
According to Hyperledger Transact’s documentation, Transact comes with the following components:
|
||||
|
||||
* **State**. The Transact state implementation provides get, set, and delete operations against a database. For the Merkle-Radix tree state implementation, the tree structure is implemented on top of LMDB or an in-memory database.
|
||||
* **Context manager**. In Transact, state reads and writes are scoped (sandboxed) to a specific “context” that contains a reference to a state ID (such as a Merkle-Radix state root hash) and one or more previous contexts. The context manager implements the context lifecycle and services the calls that read, write, and delete data from state.
|
||||
* **Scheduler**. This component controls the order of transactions to be executed. Concrete implementations include a serial scheduler and a parallel scheduler. Parallel transaction execution is an important innovation for increasing network throughput.
|
||||
* **Executor**. The Transact executor obtains transactions from the scheduler and executes them against a specific context. Execution is handled by sending the transaction to specific execution adapters (such as ZMQ or a static in-process adapter) which, in turn, send the transaction to a specific smart contract.
|
||||
* **Smart Contract Engines**. These components provide the virtual machine implementations and interpreters that run the smart contracts. Examples of engines include WebAssembly, Ethereum Virtual Machine, Sawtooth Transactions Processors, and Fabric Chaincode.
|
||||
|
||||
|
||||
|
||||
For more detailed discussion on its implementation, visit the link provided in the References section.
|
||||
|
||||
** Summary**
|
||||
|
||||
In this article, we reviewed four Hyperledger libraries that are great resources for managing Hyperledger DLTs. We started by explaining Hyperledger Aries, which is infrastructure for blockchain-rooted, peer-to-peer interactions and includes a shared cryptographic wallet for blockchain clients as well as a communications protocol for allowing off-ledger interactions between those clients. Then, we learned that Hyperledger Quilt is the interoperability tool between ledger systems and is written in Java by implementing the ILP for atomic swaps. While the Interledger is a protocol for making transactions across ledgers, ILP is a payment protocol designed to transfer value across non-distributed and distributed ledgers. We also discussed that Hyperledger Ursa is a shared cryptographic library that would enable people (and projects) to avoid duplicating other cryptographic work and hopefully increase security in the process. The library would be an opt-in repository for Hyperledger projects (and, potentially others) to place and use crypto. We concluded our article by reviewing Hyperledger Transact by which smart contracts can be executed irrespective of DLTs being used. Specifically, Transact achieves that by offering an extensible approach to implementing new smart contract languages called “smart contract engines.”
|
||||
|
||||
**References**
|
||||
|
||||
For more references on all Hyperledger projects, libraries and tools, visit the below documentation links:
|
||||
|
||||
1. [Hyperledger Indy Project][4]
|
||||
2. [Hyperledger Fabric Project][5]
|
||||
3. [Hyperledger Aries Library][6]
|
||||
4. [Hyperledger Iroha Project][7]
|
||||
5. [Hyperledger Sawtooth Project][8]
|
||||
6. [Hyperledger Besu Project][9]
|
||||
7. [Hyperledger Quilt Library][10]
|
||||
8. [Hyperledger Ursa Library][11]
|
||||
9. [Hyperledger Transact Library][12]
|
||||
10. [Hyperledger Cactus Project][13]
|
||||
11. [Hyperledger Caliper Tool][14]
|
||||
12. [Hyperledger Cello Tool][15]
|
||||
13. [Hyperledger Explorer Tool][16]
|
||||
14. [Hyperledger Grid (Domain Specific)][17]
|
||||
15. [Hyperledger Burrow Project][18]
|
||||
16. [Hyperledger Avalon Tool][19]
|
||||
|
||||
|
||||
|
||||
**Resources**
|
||||
|
||||
* Free Training Courses from The Linux Foundation & Hyperledger
|
||||
* [Blockchain: Understanding Its Uses and Implications (LFS170)][20]
|
||||
* [Introduction to Hyperledger Blockchain Technologies (LFS171)][21]
|
||||
* [Introduction to Hyperledger Sovereign Identity Blockchain Solutions: Indy, Aries & Ursa (LFS172)][22]
|
||||
* [Becoming a Hyperledger Aries Developer (LFS173)][23]
|
||||
* [Hyperledger Sawtooth for Application Developers (LFS174)][24]
|
||||
* eLearning Courses from The Linux Foundation & Hyperledger
|
||||
* [Hyperledger Fabric Administration (LFS272)][25]
|
||||
* [Hyperledger Fabric for Developers (LFD272)][26]
|
||||
* Certification Exams from The Linux Foundation & Hyperledger
|
||||
* [Certified Hyperledger Fabric Administrator (CHFA)][27]
|
||||
* [Certified Hyperledger Fabric Developer (CHFD)][28]
|
||||
* [Hands-On Smart Contract Development with Hyperledger Fabric V2][29] Book by Matt Zand and others.
|
||||
* [Essential Hyperledger Sawtooth Features for Enterprise Blockchain Developers][30]
|
||||
* [Blockchain Developer Guide- How to Install Hyperledger Fabric on AWS][31]
|
||||
* [Blockchain Developer Guide- How to Install and work with Hyperledger Sawtooth][32]
|
||||
* [Intro to Blockchain Cybersecurity][33]
|
||||
* [Intro to Hyperledger Sawtooth for System Admins][34]
|
||||
* [Blockchain Developer Guide- How to Install Hyperledger Iroha on AWS][35]
|
||||
* [Blockchain Developer Guide- How to Install Hyperledger Indy and Indy CLI on AWS][36]
|
||||
* [Blockchain Developer Guide- How to Configure Hyperledger Sawtooth Validator and REST API on AWS][37]
|
||||
* [Intro blockchain development with Hyperledger Fabric][38]
|
||||
* [How to build DApps with Hyperledger Fabric][39]
|
||||
* [Blockchain Developer Guide- How to Build Transaction Processor as a Service and Python Egg for Hyperledger Sawtooth][40]
|
||||
* [Blockchain Developer Guide- How to Create Cryptocurrency Using Hyperledger Iroha CLI][41]
|
||||
* [Blockchain Developer Guide- How to Explore Hyperledger Indy Command Line Interface][42]
|
||||
* [Blockchain Developer Guide- Comprehensive Blockchain Hyperledger Developer Guide from Beginner to Advance Level][43]
|
||||
* [Blockchain Management in Hyperledger for System Admins][44]
|
||||
* [Hyperledger Fabric for Developers][45]
|
||||
|
||||
|
||||
|
||||
**About Author**
|
||||
|
||||
**Matt Zand** is a serial entrepreneur and the founder of three tech startups: [DC Web Makers][46], [Coding Bootcamps][47] and [High School Technology Services][48]. He is a leading author of [Hands-on Smart Contract Development with Hyperledger Fabric][29] book by O’Reilly Media. He has written more than 100 technical articles and tutorials on blockchain development for Hyperledger, Ethereum and Corda R3 platforms at sites such as IBM, SAP, Alibaba Cloud, Hyperledger, The Linux Foundation, and more. As a public speaker, he has presented webinars at many Hyperledger communities across USA and Europe . At DC Web Makers, he leads a team of blockchain experts for consulting and deploying enterprise decentralized applications. As chief architect, he has designed and developed blockchain courses and training programs for Coding Bootcamps. He has a master’s degree in business management from the University of Maryland. Prior to blockchain development and consulting, he worked as senior web and mobile App developer and consultant, angel investor, business advisor for a few startup companies. You can connect with him on [LinkedIn][49].
|
||||
|
||||
The post [Review of Four Hyperledger Libraries- Aries, Quilt, Ursa, and Transact][50] appeared first on [Linux Foundation – Training][51].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.linux.com/news/review-of-four-hyperledger-libraries-aries-quilt-ursa-and-transact/
|
||||
|
||||
作者：[Dan Brown][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://training.linuxfoundation.org/announcements/review-of-four-hyperledger-libraries-aries-quilt-ursa-and-transact/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://training.linuxfoundation.org/announcements/review-of-five-popular-hyperledger-dlts-fabric-besu-sawtooth-iroha-and-indy/
|
||||
[2]: https://training.linuxfoundation.org/announcements/review-of-three-hyperledger-tools-caliper-cello-and-avalon/
|
||||
[3]: https://www.hyperledger.org/blog/2021/02/26/hyperledger-aries-graduates-to-active-status-joins-indy-as-production-ready-hyperledger-projects-for-decentralized-identity
|
||||
[4]: https://www.hyperledger.org/use/hyperledger-indy
|
||||
[5]: https://www.hyperledger.org/use/fabric
|
||||
[6]: https://www.hyperledger.org/projects/aries
|
||||
[7]: https://www.hyperledger.org/projects/iroha
|
||||
[8]: https://www.hyperledger.org/projects/sawtooth
|
||||
[9]: https://www.hyperledger.org/projects/besu
|
||||
[10]: https://www.hyperledger.org/projects/quilt
|
||||
[11]: https://www.hyperledger.org/projects/ursa
|
||||
[12]: https://www.hyperledger.org/projects/transact
|
||||
[13]: https://www.hyperledger.org/projects/cactus
|
||||
[14]: https://www.hyperledger.org/projects/caliper
|
||||
[15]: https://www.hyperledger.org/projects/cello
|
||||
[16]: https://www.hyperledger.org/projects/explorer
|
||||
[17]: https://www.hyperledger.org/projects/grid
|
||||
[18]: https://www.hyperledger.org/projects/hyperledger-burrow
|
||||
[19]: https://www.hyperledger.org/projects/avalon
|
||||
[20]: https://training.linuxfoundation.org/training/blockchain-understanding-its-uses-and-implications/
|
||||
[21]: https://training.linuxfoundation.org/training/blockchain-for-business-an-introduction-to-hyperledger-technologies/
|
||||
[22]: https://training.linuxfoundation.org/training/introduction-to-hyperledger-sovereign-identity-blockchain-solutions-indy-aries-and-ursa/
|
||||
[23]: https://training.linuxfoundation.org/training/becoming-a-hyperledger-aries-developer-lfs173/
|
||||
[24]: https://training.linuxfoundation.org/training/hyperledger-sawtooth-application-developers-lfs174/
|
||||
[25]: https://training.linuxfoundation.org/training/hyperledger-fabric-administration-lfs272/
|
||||
[26]: https://training.linuxfoundation.org/training/hyperledger-fabric-for-developers-lfd272/
|
||||
[27]: https://training.linuxfoundation.org/certification/certified-hyperledger-fabric-administrator-chfa/
|
||||
[28]: https://training.linuxfoundation.org/certification/certified-hyperledger-fabric-developer/
|
||||
[29]: https://www.oreilly.com/library/view/hands-on-smart-contract/9781492086116/
|
||||
[30]: https://weg2g.com/application/touchstonewords/article-essential-hyperledger-sawtooth-features-for-enterprise-blockchain-developers.php
|
||||
[31]: https://myhsts.org/tutorial-learn-how-to-install-blockchain-hyperledger-fabric-on-amazon-web-services.php
|
||||
[32]: https://myhsts.org/tutorial-learn-how-to-install-and-work-with-blockchain-hyperledger-sawtooth.php
|
||||
[33]: https://learn.coding-bootcamps.com/p/learn-how-to-secure-blockchain-applications-by-examples
|
||||
[34]: https://learn.coding-bootcamps.com/p/introduction-to-hyperledger-sawtooth-for-system-admins
|
||||
[35]: https://myhsts.org/tutorial-learn-how-to-install-blockchain-hyperledger-iroha-on-amazon-web-services.php
|
||||
[36]: https://myhsts.org/tutorial-learn-how-to-install-blockchain-hyperledger-indy-on-amazon-web-services.php
|
||||
[37]: https://myhsts.org/tutorial-learn-how-to-configure-hyperledger-sawtooth-validator-and-rest-api-on-aws.php
|
||||
[38]: https://learn.coding-bootcamps.com/p/live-and-self-paced-blockchain-development-with-hyperledger-fabric
|
||||
[39]: https://learn.coding-bootcamps.com/p/live-crash-course-for-building-dapps-with-hyperledger-fabric
|
||||
[40]: https://myhsts.org/tutorial-learn-how-to-build-transaction-processor-as-a-service-and-python-egg-for-hyperledger-sawtooth.php
|
||||
[41]: https://myhsts.org/tutorial-learn-how-to-work-with-hyperledger-iroha-cli-to-create-cryptocurrency.php
|
||||
[42]: https://myhsts.org/tutorial-learn-how-to-work-with-hyperledger-indy-command-line-interface.php
|
||||
[43]: https://myhsts.org/tutorial-comprehensive-blockchain-hyperledger-developer-guide-for-all-professional-programmers.php
|
||||
[44]: https://learn.coding-bootcamps.com/p/learn-blockchain-development-with-hyperledger-by-examples
|
||||
[45]: https://learn.coding-bootcamps.com/p/hyperledger-blockchain-development-for-developers
|
||||
[46]: https://blockchain.dcwebmakers.com/
|
||||
[47]: http://coding-bootcamps.com/
|
||||
[48]: https://myhsts.org/
|
||||
[49]: https://www.linkedin.com/in/matt-zand-64047871
|
||||
[50]: https://training.linuxfoundation.org/announcements/review-of-four-hyperledger-libraries-aries-quilt-ursa-and-transact/
|
||||
[51]: https://training.linuxfoundation.org/
|
||||
@ -0,0 +1,90 @@
|
||||
[#]: subject: (Set up network parental controls on a Raspberry Pi)
|
||||
[#]: via: (https://opensource.com/article/21/3/raspberry-pi-parental-control)
|
||||
[#]: author: (Daniel Oh https://opensource.com/users/daniel-oh)
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
Set up network parental controls on a Raspberry Pi
|
||||
======
|
||||
With minimal investment of time and money, you can keep your kids safe
|
||||
online.
|
||||
![Family learning and reading together at night in a room][1]
|
||||
|
||||
Parents are always looking for ways to protect their kids online—from malware, banner ads, pop-ups, activity-tracking scripts, and other concerns—and to prevent them from playing games and watching YouTube when they should be doing their schoolwork. Many businesses use tools that regulate their employees' online safety and activities, but the question is how to make this happen at home?
|
||||
|
||||
The short answer is a tiny, inexpensive Raspberry Pi computer that enables you to set parental controls for your kids and your work at home. This article walks you through how easy it is to build your own parental control-enabled home network with a Raspberry Pi.
|
||||
|
||||
### Install the hardware and software
|
||||
|
||||
For this project, you'll need a Raspberry Pi and a home network router. If you spend only five minutes exploring online shopping sites, you will find a lot of options. The [Raspberry Pi 4][2] and a [TP-Link router][3] are good options for beginners.
|
||||
|
||||
Once you have your network device and Pi, you need to install [Pi-hole][4] as a Linux container or a supported operating system. There are several [ways to install it][5], but an easy way is to issue the following command on your Pi:
|
||||
|
||||
|
||||
```
|
||||
`curl -sSL https://install.pi-hole.net | bash`
|
||||
```
|
||||
|
||||
### Configure Pi-hole as your DNS server
|
||||
|
||||
Next, you need to configure the DHCP settings in both your router and Pi-hole:
|
||||
|
||||
1. Disable the DHCP server setting in your router
|
||||
2. Enable the DHCP server in Pi-hole
|
||||
|
||||
|
||||
|
||||
Every device is different, so there's no way for me to tell you exactly what you need to click on to adjust your settings. Generally, you access your home router through a web browser. Your router's address is sometimes printed on the bottom of the router, and it begins with either 192.168 or 10.
|
||||
|
||||
In your web browser, navigate to your router's address and log in with the credentials you received when you got your internet service. It's often as simple as `admin` with a numeric password (sometimes this password is also printed on the router). If you don't know the login, call your internet provider and ask for details.
|
||||
|
||||
In the graphical interface, look for a section within your LAN about DHCP, and deactivate the DHCP server. Your router's interface will almost certainly look different from mine, but this is an example of what I saw when setting it up. Uncheck **DHCP server**:
|
||||
|
||||
![Disable DHCP][6]
|
||||
|
||||
(Daniel Oh, [CC BY-SA 4.0][7])
|
||||
|
||||
Next, you _must_ activate the DHCP server on the Pi-hole. If you don't do that, none of your devices will be able to get online unless you manually assign IP addresses!
|
||||
|
||||
### Make your network family-friendly
|
||||
|
||||
You're all set. Now, your network devices (i.e., mobile phone, tablet PC, laptop, etc.) will automatically find the DHCP server on the Raspberry Pi. Then, each device will be assigned a dynamic IP address to access the internet.
|
||||
|
||||
Note: If your router device supports setting a DNS server, you can also configure the DNS clients in your router. The client will refer to the Pi-hole as your DNS server.
|
||||
|
||||
To set up rules for which sites and activities your kids can access, open a web browser to the Pi-hole admin page, `http://pi.hole/admin/`. On the dashboard, click on **Whitelist** to add web pages your kids are allowed to access. You can also add sites that your kids aren't allowed to access (e.g., gaming, adult, ads, shopping, etc.) to the **Blocklist**.
|
||||
|
||||
![Pi-hole admin dashboard][8]
|
||||
|
||||
(Daniel Oh, [CC BY-SA 4.0][7])
|
||||
|
||||
### What's next?
|
||||
|
||||
Now that you've set up your Raspberry Pi for parental control, you can keep your kids safer online while giving them access to approved entertainment options. This can also decrease your home internet usage by reducing how much your family is streaming. For more advanced usage, access Pi-hole's [documentation][9] and [blogs][10].
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/21/3/raspberry-pi-parental-control
|
||||
|
||||
作者：[Daniel Oh][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/daniel-oh
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/family_learning_kids_night_reading.png?itok=6K7sJVb1 (Family learning and reading together at night in a room)
|
||||
[2]: https://www.raspberrypi.org/products/
|
||||
[3]: https://www.amazon.com/s?k=tp-link+router&crid=3QRLN3XRWHFTC&sprefix=TP-Link%2Caps%2C186&ref=nb_sb_ss_ts-doa-p_3_7
|
||||
[4]: https://pi-hole.net/
|
||||
[5]: https://github.com/pi-hole/pi-hole/#one-step-automated-install
|
||||
[6]: https://opensource.com/sites/default/files/uploads/disabledhcp.jpg (Disable DHCP)
|
||||
[7]: https://creativecommons.org/licenses/by-sa/4.0/
|
||||
[8]: https://opensource.com/sites/default/files/uploads/blocklist.png (Pi-hole admin dashboard)
|
||||
[9]: https://docs.pi-hole.net/
|
||||
[10]: https://pi-hole.net/blog/#page-content
|
||||
@ -1,262 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (stevenzdg988)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Testing Bash with BATS)
|
||||
[#]: via: (https://opensource.com/article/19/2/testing-bash-bats)
|
||||
[#]: author: (Darin London https://opensource.com/users/dmlond)
|
||||
|
||||
利用 BATS 测试 Bash
|
||||
======
|
||||
Bash 自动测试系统通过 Java，Ruby 和 Python 开发人员所使用的相同类型的测试进程来提交 Bash 代码。
|
||||
|
||||
|
||||
|
||||
用Java，Ruby和Python等语言编写应用程序的软件开发人员拥有完善的库，可以帮助他们随着时间的推移保持软件的完整性。他们创建测试，以在结构化环境中通过一系列执行来运行应用程序，以确保其所有软件方面均按预期工作。
|
||||
|
||||
当这些测试在持续集成（CI）系统中自动化时甚至会更加健壮，在这种情况下，每次推送到源知识库都会使测试运行，并且在测试失败时会立即通知开发人员。这种快速反馈提高了开发人员对其应用程序功能完整性的信心。
|
||||
|
||||
Bash 自动测试系统（[BATS][1]）使开发人员能够编写 Bash 脚本和库，以将Java，Ruby，Python 和其他开发人员所使用的相同惯例应用于其 Bash 代码。
|
||||
|
||||
### 安装 BATS
|
||||
|
||||
BATS GitHub 页面包含安装指令。有两个 BATS 帮助程序函数库，它们提供更强大的断言或允许使用 BATS 重写 Test Anything Protocol(测试协议)([TAP][2])输出格式。可以将它们安装在标准位置，并由所有脚本提供。在 Git 知识库中包含完整版本的 BATS 及其帮助函数库对于要测试的每组脚本或函数库可能会更实用。这可以使用 **[git submodule][3]** (git 子模块)系统来完成。
|
||||
|
||||
以下命令会将 BATS 及其帮助函数库安装到 Git 知识库中的 **test** 目录中。
|
||||
|
||||
```
|
||||
git submodule init
|
||||
git submodule add https://github.com/sstephenson/bats test/libs/bats
|
||||
git submodule add https://github.com/ztombol/bats-assert test/libs/bats-assert
|
||||
git submodule add https://github.com/ztombol/bats-support test/libs/bats-support
|
||||
git add .
|
||||
git commit -m 'installed bats'
|
||||
```
|
||||
|
||||
要克隆 Git 知识库并同时安装其子模块，请使用
|
||||
**\-recurse-submodules** 为 **git clone** 标记。
|
||||
|
||||
每个 BATS 测试脚本必须由 **bats** 可执行文件执行。如果您将 BATS 安装到源代码知识库的 **test/libs** 目录中，则可以使用以下命令调用测试：
|
||||
|
||||
```
|
||||
./test/libs/bats/bin/bats <path to test script>
|
||||
```
|
||||
|
||||
或者，将以下内容添加到每个 BATS 测试脚本的开头：
|
||||
|
||||
```
|
||||
#!/usr/bin/env ./test/libs/bats/bin/bats
|
||||
load 'libs/bats-support/load'
|
||||
load 'libs/bats-assert/load'
|
||||
```
|
||||
|
||||
并且执行命令 **chmod +x <测试脚本的路径>**。 这将 a) 使它们与安装在 **./test/libs/bats** 中的 BATS 可执行，并且 b) 包括这些帮助函数库。BATS 测试脚本通常存储在 **test** 目录中，并为要测试的脚本命名，扩展名为 **.bats**。例如，测试 **bin/build** 的 BATS 脚本应称为 **test/build.bats**。
|
||||
|
||||
您还可以通过正则表达式传递给 BATS 来运行整套 BATS 测试文件，例如 **./test/lib/bats/bin/bats test/*.bats**。
|
||||
|
||||
### 为 BATS 组织函数库和脚本的重写范围
|
||||
|
||||
Bash 脚本和库必须以一种有效地将其内部工作暴露给 BATS 的方式进行组织。通常，在调用或执行时库函数和运行诸多命令的 Shell 脚本不适合进行有效的 BATS 测试。
|
||||
|
||||
例如，[build.sh][4] 是许多人编写的典型脚本。本质上是一大堆代码。有些人甚至可能将这堆代码放入库中的函数中。但是，不可能在 BATS 测试中运行大量代码并涵盖在单独的测试用例中可能遇到的所有类型的故障。测试具有足够重写范围的这堆代码的唯一方法是将其分解为许多小的，可重用的，最重要的是可独立测试的功能。
|
||||
|
||||
向库添加更多功能(函数)很简单。额外的好处是其中一些功能本身可以变得出奇的有用。将库函数分解为许多较小的函数后，您可以在 BATS 测试中 **source** 库，并像测试任何其他命令一样运行这些函数。
|
||||
|
||||
Bash 脚本还必须分解为多个函数，执行脚本时，脚本的主要部分应调用这些函数。此外，还有一个非常有用的技巧，可以使使用 BATS 测试 Bash 脚本变得更加容易：将脚本主要部分中执行的所有代码都移到一个函数中，称为 **run_main**。然后，将以下内容添加到脚本的末尾：
|
||||
|
||||
```
|
||||
if [[ "${BASH_SOURCE[0]}" == "${0}" ]]
|
||||
then
|
||||
run_main
|
||||
fi
|
||||
```
|
||||
|
||||
这段额外的代码做了一些特殊的事情。它使脚本当作为脚本执行时与使用 **source** 进入环境时的行为有所不同。此技巧使通过与测试库相同的方式测试脚本和测试各个函数功能成为可能。例如，利用脚本 [build.sh 重构以获得更好的 BATS 可测试性][5]。
|
||||
|
||||
### 编写和运行测试
|
||||
|
||||
如上所述，BATS 是一个 TAP 兼容测试框架，其语法和输出对于使用过其他 TAP 兼容测试套件（例如 JUnit，RSpec 或 Jest）的用户来说将是熟悉的。它的测试被组织进各个测试脚本。测试脚本被组织进一个或多个描述性 **@test** 块中，它们描述了被测试应用程序的单元。每个 **@test** 块都将运行一系列准备测试环境命令，运行要测试的命令，并对退出和被测试命令的输出进行断言。许多断言函数是通过 **bats** , **bats-assert** , 和 **bats-support** 库导入的，这些库在 BATS 测试脚本的开头加载到环境中。下面是一个典型的 BATS 测试块：
|
||||
|
||||
```
|
||||
@test "requires CI_COMMIT_REF_SLUG environment variable" {
|
||||
unset CI_COMMIT_REF_SLUG
|
||||
assert_empty "${CI_COMMIT_REF_SLUG}"
|
||||
run some_command
|
||||
assert_failure
|
||||
assert_output --partial "CI_COMMIT_REF_SLUG"
|
||||
}
|
||||
```
|
||||
|
||||
如果 BATS 脚本包含 **setup(安装)** 和/或 **teardown(拆卸)** 功能，则 BATS 将在每个测试块运行之前和之后自动执行它们。这样就可以创建环境变量，测试文件以及执行一个或所有测试所需的其他操作，然后在每次测试运行后将其拆卸。[**Build.bats**][6] 是对我们新格式化的 **build.sh** 脚本的完整 BATS 测试。（此测试中的 **mock_docker** 命令将在以下关于模拟/桩的部分中进行说明。）
|
||||
|
||||
当测试脚本运行时，BATS 使用 **exec** 来将每个 **@test** 块作为单独的子进程运行。这样就可以在一个 **@test** 中导出环境变量甚至函数，而不会影响其他 **@test** 或污染您当前的 Shell 会话。测试运行的输出是一种标准格式，可以被人理解，并且可以由 TAP 用户以编程方式进行解析或操作。下面是 **CI_COMMIT_REF_SLUG** 测试块失败时的输出示例：
|
||||
|
||||
```
|
||||
✗ requires CI_COMMIT_REF_SLUG environment variable
|
||||
(from function `assert_output' in file test/libs/bats-assert/src/assert.bash, line 231,
|
||||
in test file test/ci_deploy.bats, line 26)
|
||||
`assert_output --partial "CI_COMMIT_REF_SLUG"' failed
|
||||
|
||||
-- output does not contain substring --
|
||||
substring (1 lines):
|
||||
CI_COMMIT_REF_SLUG
|
||||
output (3 lines):
|
||||
./bin/deploy.sh: join_string_by: command not found
|
||||
oc error
|
||||
Could not login
|
||||
--
|
||||
|
||||
** Did not delete , as test failed **
|
||||
|
||||
1 test, 1 failure
|
||||
```
|
||||
|
||||
下面是成功测试的输出：
|
||||
|
||||
```
|
||||
✓ requires CI_COMMIT_REF_SLUG environment variable
|
||||
```
|
||||
|
||||
### 助手
|
||||
|
||||
像任何 Shell 脚本或库一样，BATS 测试脚本可以包括帮助程序库，以在测试之间共享通用代码或增强其性能。这些帮助程序库，例如 **bats-assert** 和 **bats-support** 甚至可以使用 BATS 进行测试。
|
||||
|
||||
如果测试目录中的文件数量庞大，则可以将库放置在同一测试目录中作为 BATS 脚本，也可以将它们放置在 **test/libs** 目录中。BATS 提供了 **load** 函数，该函数采用相对于要测试的脚本的 Bash 文件的路径（例如，在我们的示例中的 **test**），并声明该文件。文件必须以前缀 **.bash** 结尾，但是传递给 **load** 函数的文件路径不能包含前缀。**build.bats** 加载 **bats-assert** 和 **bats-support** 库，一个小型 **[helpers.bash][7]** 库以及 **docker_mock.bash** 库（如下所述），以下代码位于解释器调谐线下方的测试脚本的开头：
|
||||
|
||||
```
|
||||
load 'libs/bats-support/load'
|
||||
load 'libs/bats-assert/load'
|
||||
load 'helpers'
|
||||
load 'docker_mock'
|
||||
```
|
||||
|
||||
### 测试输入桩和模拟外部调用
|
||||
|
||||
大多数 Bash 脚本和库运行时执行函数和(或)可执行文件。通常，它们被程序化为基于特定方式运行退出状态或这些函数或可执行文件的输出（**stdout**，**stderr**）。为了正确地测试这些脚本，通常需要制作这些命令的伪版本，这些被设计用来在特定测试过程中以特定方式运行，称为“桩(桩？)”。可能还需要监视正在测试的程序，以确保其调用了特定命令，或者使用特定参数调用了特定命令，此过程称为“模拟”。有关更多信息，请查看在 Ruby RSpec 中适用于任何测试系统的伟大的 [有关模拟和桩的讨论][8]。
|
||||
|
||||
Bash shell 提供了的技巧，可以在您的 BATS 测试脚本中使用进行模拟和桩。所有这些都需要使用带有 **-f** 标志的 Bash **export** 命令来导出重写原始函数或可执行文件的函数。必须在测试程序执行之前完成此操作。下面是重写可执行命令 **cat** 的简单示例：
|
||||
|
||||
```
|
||||
function cat() { echo "THIS WOULD CAT ${*}" }
|
||||
export -f cat
|
||||
```
|
||||
|
||||
此方法以相同的方式重写函数。如果测试需要重写要测试的脚本或库中的函数，则在对函数进行桩或模拟之前，必须先声明已测试脚本或库，这一点很重要。否则，在声明脚本时，桩/模拟将被原函数替代。另外，在运行即将进行的测试命令之前确认桩/模拟。下面是**build.bats**的示例，该示例模拟**build.sh**中描述的**raise**函数，以确保利用登录函数引发特定的错误消息：
|
||||
|
||||
```
|
||||
@test ".login raises on oc error" {
|
||||
source ${profile_script}
|
||||
function raise() { echo "${1} raised"; }
|
||||
export -f raise
|
||||
run login
|
||||
assert_failure
|
||||
assert_output -p "Could not login raised"
|
||||
}
|
||||
```
|
||||
|
||||
一般情况下，没有必要在测试后复原桩/模拟功能，因为 **export**（输出）仅在当前 **@test** 块的 **exec**（执行）期间影响当前子进程。但是，可以模拟/桩 BATS **assert** 函数在内部使用的命令（例如**cat**，**sed**等）是可能的。在运行这些断言命令之前，必须对这些模拟/桩函数进行 **unset**（复原） ，否则它们将无法正常工作。下面是 **build.bats** 中的一个示例，该示例模拟 **sed**，运行 **build_deployable** 函数并在运行任何断言之前复原 **sed**：
|
||||
|
||||
```
|
||||
@test ".build_deployable prints information, runs docker build on a modified Dockerfile.production and publish_image when its not a dry_run" {
|
||||
local expected_dockerfile='Dockerfile.production'
|
||||
local application='application'
|
||||
local environment='environment'
|
||||
local expected_original_base_image="${application}"
|
||||
local expected_candidate_image="${application}-candidate:${environment}"
|
||||
local expected_deployable_image="${application}:${environment}"
|
||||
source ${profile_script}
|
||||
mock_docker build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t "${expected_deployable_image}" -
|
||||
function publish_image() { echo "publish_image ${*}"; }
|
||||
export -f publish_image
|
||||
function sed() {
|
||||
echo "sed ${*}" >&2;
|
||||
echo "FROM application-candidate:environment";
|
||||
}
|
||||
export -f sed
|
||||
run build_deployable "${application}" "${environment}"
|
||||
assert_success
|
||||
unset sed
|
||||
assert_output --regexp "sed.*${expected_dockerfile}"
|
||||
assert_output -p "Building ${expected_original_base_image} deployable ${expected_deployable_image} FROM ${expected_candidate_image}"
|
||||
assert_output -p "FROM ${expected_candidate_image} piped"
|
||||
assert_output -p "build --build-arg OAUTH_CLIENT_ID --build-arg OAUTH_REDIRECT --build-arg DDS_API_BASE_URL -t ${expected_deployable_image} -"
|
||||
assert_output -p "publish_image ${expected_deployable_image}"
|
||||
}
|
||||
```
|
||||
|
||||
有的时候相同的命令，例如 `foo`，将在被测试的同一函数中使用不同的参数多次调用。 这些情况需要创建一组函数：
|
||||
|
||||
* mock_foo：将期望的参数作为输入，并将其持久化到 TMP 文件中
|
||||
* foo：命令的模拟版本，该命令使用持久化的预期参数列表处理每个调用。必须使用 `export -f` 将其导出。
|
||||
* cleanup_foo：删除 TMP 文件，用于拆卸函数。这可以进行测试以确保在删除之前成功完成 `@test` 块。
|
||||
|
||||
由于此功能通常在不同的测试中重复使用，因此创建可以像其他库一样加载的帮助程序库会变得有意义。
|
||||
|
||||
**[docker_mock.bash][9]**是一个很棒的例子。它被加载到 **build.bats** 中，并在任何测试调用 Docker 可执行文件的函数的测试块中使用。使用 **docker_mock** 典型的测试块如下所示：
|
||||
|
||||
```
|
||||
@test ".publish_image fails if docker push fails" {
|
||||
setup_publish
|
||||
local expected_image="image"
|
||||
local expected_publishable_image="${CI_REGISTRY_IMAGE}/${expected_image}"
|
||||
source ${profile_script}
|
||||
mock_docker tag "${expected_image}" "${expected_publishable_image}"
|
||||
mock_docker push "${expected_publishable_image}" and_fail
|
||||
run publish_image "${expected_image}"
|
||||
assert_failure
|
||||
assert_output -p "tagging ${expected_image} as ${expected_publishable_image}"
|
||||
assert_output -p "tag ${expected_image} ${expected_publishable_image}"
|
||||
assert_output -p "pushing image to gitlab registry"
|
||||
assert_output -p "push ${expected_publishable_image}"
|
||||
}
|
||||
```
|
||||
|
||||
该测试建立了一个使用不同的参数两次调用 Docker 的预期。在对Docker 的第二次调用失败时，将运行测试命令，然后测试退出状态和对 Docker 调用的预期。
|
||||
|
||||
一方面 BATS 利用 **mock_docker.bash** 引入 **${BATS_TMPDIR}** 环境变量，BATS 在测试开始的位置对其进行了设置，以允许测试和助手程序在标准位置创建和销毁 TMP 文件。如果测试失败，**mock_docker.bash** 库将不会删除其持久化的模拟文件，但会在其所在位置进行打印，以便可以查看和删除它。您可能需要定期从该目录中清除旧的模拟文件。
|
||||
|
||||
请注意关于模拟/桩的警告：**build.bats** 测试有意识地违反了关于测试声明的规定：[不要模拟没有拥有的！][10]该规定要求调用开发人员没有编写代码的测试命令，例如 **docker**，**cat**，**sed**等，应封装在自己的库中，应在使用它们脚本的测试中对其进行模拟。然后应该在不模拟外部命令的情况下测试封装库。
|
||||
|
||||
这是一个很好的建议，而忽略它是有代价的。如果 Docker CLI API 发生变化，则测试脚本将不会检测到此变化，从而导致一个错误内容直到经过测试的 **build.sh** 脚本在使用新版本 Docker 的生产环境中运行后才显示出来。测试开发人员必须确定要严格遵守此标准的程度，但是他们应该了解其所涉及的权衡。
|
||||
|
||||
### 总结
|
||||
|
||||
在任何软件开发项目中引入测试方案都会在 a）增加开发和维护代码及测试所需的时间和组织与 b）增加开发人员在对应用程序整个生命周期中完整性的信心之间进行权衡。测试方案可能不适用于所有脚本和库。
|
||||
|
||||
通常，满足以下一个或多个条件的脚本和库才可以使用 BATS 测试：
|
||||
|
||||
* They are used by others
|
||||
* 值得存储在源代码管理中
|
||||
* 用于关键进程中，并可以长期稳定运行
|
||||
* 需要定期对其进行修改以添加/删除/修改其函数
|
||||
* 可以被其他人使用
|
||||
|
||||
一旦决定将测试规则应用于一个或多个 Bash 脚本或库，BATS 将提供其他软件开发环境中可用的全面测试功能。
|
||||
|
||||
致谢：感激[Darrin Mann][11]向我引荐了 BATS 测试。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/2/testing-bash-bats
|
||||
|
||||
作者：[Darin London][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[stevenzdg988](https://github.com/stevenzdg988)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/dmlond
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://github.com/sstephenson/bats
|
||||
[2]: http://testanything.org/
|
||||
[3]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
|
||||
[4]: https://github.com/dmlond/how_to_bats/blob/preBats/build.sh
|
||||
[5]: https://github.com/dmlond/how_to_bats/blob/master/bin/build.sh
|
||||
[6]: https://github.com/dmlond/how_to_bats/blob/master/test/build.bats
|
||||
[7]: https://github.com/dmlond/how_to_bats/blob/master/test/helpers.bash
|
||||
[8]: https://www.codewithjason.com/rspec-mocks-stubs-plain-english/
|
||||
[9]: https://github.com/dmlond/how_to_bats/blob/master/test/docker_mock.bash
|
||||
[10]: https://github.com/testdouble/contributing-tests/wiki/Don't-mock-what-you-don't-own
|
||||
[11]: https://github.com/dmann
|
||||
@ -0,0 +1,135 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (stevenzdg988)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (6 best practices for managing Git repos)
|
||||
[#]: via: (https://opensource.com/article/20/7/git-repos-best-practices)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/seth)
|
||||
|
||||
6 个最佳的 Git 仓库管理实践
|
||||
======
|
||||
阻止向 Git 中添加内容的主张会使其变得更难管理；
|
||||
这里有替代方法。
|
||||
![在家中使用笔记本电脑工作][1]
|
||||
|
||||
有权访问源代码使对安全性的分析以及应用程序的安全成为可能。但是，如果没有人真正看过代码，问题就不会被发现，即使人们积极地看代码，通常也要看很多东西。幸运的是，GitHub 拥有一个活跃的安全团队，最近，他们 [发现了已提交到多个 Git 存储库中的特洛伊木马病毒][2]，甚至仓库的所有者也偷偷溜走了。尽管我们无法控制其他人如何管理自己的存储库，但我们可以从他们的错误中吸取教训。为此，本文回顾了将文件添加到自己的存储库中的一些最佳实践。
|
||||
|
||||
### 了解您的仓库
|
||||
|
||||
![Git 存储库终端][3]
|
||||
|
||||
对于安全的 Git 存储库来说大概是 Rule Zero (头号规则)。作为项目维护者，无论您是从自己的开始还是采用别人的，您的工作是了解自己存储库中的内容。您可能没有代码库中关于每个文件的存储列表，但是您需要了解所管理内容的基本组成。如果几十个合并后出现一个偏离的文件，您将可以很容易地识别它，因为您不知道它的用途，并且需要刷新内存检查它。发生这种情况时，请查看文件，并确保准确了解为什么它是必要的。
|
||||
|
||||
### 禁止二进制大文件
|
||||
|
||||
![终端中 Git 的二进制检查命令][4]
|
||||
|
||||
Git 用于文本，无论是用纯文本编写的 C 或 Python 还是 Java 文本，亦或是 JSON，YAML，XML，Markdown，HTML 或类似的文本。Git 对于二进制文件不是很理想。
|
||||
|
||||
两者之间的区别是：
|
||||
|
||||
```
|
||||
$ cat hello.txt
|
||||
This is plain text.
|
||||
It's readable by humans and machines alike.
|
||||
Git knows how to version this.
|
||||
|
||||
$ git diff hello.txt
|
||||
diff --git a/hello.txt b/hello.txt
|
||||
index f227cc3..0d85b44 100644
|
||||
\--- a/hello.txt
|
||||
+++ b/hello.txt
|
||||
@@ -1,2 +1,3 @@
|
||||
This is plain text.
|
||||
+It's readable by humans and machines alike.
|
||||
Git knows how to version this.
|
||||
```
|
||||
|
||||
和
|
||||
|
||||
```
|
||||
$ git diff pixel.png
|
||||
diff --git a/pixel.png b/pixel.png
|
||||
index 563235a..7aab7bc 100644
|
||||
Binary files a/pixel.png and b/pixel.png differ
|
||||
|
||||
$ cat pixel.png
|
||||
<EFBFBD>PNG
|
||||
▒
|
||||
IHDR7n<EFBFBD>$gAMA<4D><41>
|
||||
<20>abKGD݊<44>tIME<4D>
|
||||
|
||||
-2R<32><52>
|
||||
IDA<EFBFBD>c`<60>!<21>3%tEXtdate:create2020-06-11T11:45:04+12:00<30><30>r.%tEXtdate:modify2020-06-11T11:45:04+12:00<30><30>ʒIEND<4E>B`<60>
|
||||
```
|
||||
|
||||
二进制文件中的数据无法以解析纯文本相同的方式进行解析，因此，如果二进制文件发生任何更改，则必须重写整个内容。一个版本与另一个版本之间的仅有地区别是快速增加的内容。
|
||||
|
||||
更糟糕的是，Git 存储库维护者无法合理地审计二进制数据。这违反了 Rule Zero (头号规则)：应该对存储库的内容了如指掌。
|
||||
|
||||
除了常用的 [POSIX(可移植性操作系统接口)][5] 工具之外，您还可以使用 `git diff` 检测二进制文件。当您尝试使用 `--numstat` 选项来比较二进制文件时，Git 返回空结果：
|
||||
|
||||
```
|
||||
$ git diff --numstat /dev/null pixel.png | tee
|
||||
\- - /dev/null => pixel.png
|
||||
$ git diff --numstat /dev/null file.txt | tee
|
||||
5788 0 /dev/null => list.txt
|
||||
```
|
||||
|
||||
如果您正在考虑将二进制大文件提交到存储库，请停下来先思考一下。如果是二进制文件，则它是由什么生成的。 有充分的理由在构建时生成它们来代替将它们提交存储库？你决定提交二进制数据可行，请确保在 README 文件或类似文件中标识二进制文件的位置，为什么是二进制的原因以及更新它们的协议。必须谨慎执行更新，因为对于提交给二进制大文件的每次更改，该二进制大文件的存储空间实际上都会加倍。
|
||||
|
||||
### 保留第三方库
|
||||
|
||||
第三方库也不例外。尽管它是开放源代码的众多优点之一，您可以不受限制地重用和重新分发未编写的代码，但是有很多充分的理由不去覆盖存储在您自己的存储库中第三方库。首先，除非您自己检查了所有代码（以及将来的合并），否则您无法准确确定第三方库。其次，当您将第三方库复制到您的 Git 存储库中时，会将焦点从真正的上游源分离出来。从技术上仅对主库的副本有把握，而不对随机存储库的副本有把握。如果您需要锁定特定版本的库，请为开发人员提供项目所需版本的合理 URL，或者使用[Git 子模块][6]。
|
||||
|
||||
### 抵制盲目的 `git add`
|
||||
|
||||
![Git 手动添加命令终端中][7]
|
||||
|
||||
如果您的项目已编译，请不要使用 `git add .`（其中 `.` 是当前目录或特定文件夹的路径）作为添加任意和每一个新内容的简单方法。如果您不是手动编译项目，而是使用 IDE 为您管理项目，则这一点尤其重要。用 IDE 管理项目时，跟踪添加到存储库中的内容非常困难，因此仅添加您实际编写的内容非常重要，而不是在项目文件夹中弹出的任何新对象。
|
||||
|
||||
如果您使用 `git add .` 做，请在推送之前检查这一状态里的情况。如果在执行 `git status` 时在项目文件夹中看到一个陌生的对象，请在运行 `make clean` 或等效命令找出它的来源以及为什么仍然在项目的目录中。这是非常好的不会在编译期间重新生成的创建方法，因此在提交前请三思。
|
||||
|
||||
### 使用 Git ignore
|
||||
|
||||
![终端中的 `Git ignore` 命令][8]
|
||||
|
||||
为程序员提供的许多方便的创建众说纷纭。任何项目，程序，富有艺术性的或其他的典型项目目录中都充斥着隐藏的文件，元数据和残留的内容。您可以尝试忽略这些对象，但是 `git status` 中的提示越多，您错过某件事的可能性就越大。
|
||||
|
||||
您可以通过维护一个良好的 `gitignore` 文件来为您过滤掉这种噪音。因为这是使用 Git 的用户的共同要求，所以有一些入门 `gitignore` 文件可用。[Github.com/github/gitignore][9] 提供了几个专门创建 `gitignore` 的文件，您可以下载这些文件并将其放置到自己的项目中，几年前 [Gitlab.com][10] 将`gitignore` 模板集成到了存储库创建工作流程中。使用这些帮助您为项目创建适合的 `gitignore` 策略并遵守它。
|
||||
|
||||
### 查看合并请求
|
||||
|
||||
![Git 合并请求][11]
|
||||
|
||||
当您通过电子邮件收到合并或拉取请求或补丁文件时，请勿仅对其进行测试以确保其正常工作。您的工作是阅读新代码进入代码库的并了解其如何产生结果。如果您不同意实施，或者更糟的是，您不理解该实施，请向提交该实施的人发送消息，并要求其进行说明。询问所依赖代码要成为存储库中永久性装置具有优先权，但是这是在你同你的用户的不知道将合并什么到他们将要使用的代码中开启的约定。
|
||||
|
||||
### Git 责任
|
||||
|
||||
社区致力于开源软件良好的安全性。不要鼓励在您的存储库中使用不良的 Git 实践，也不要忽视克隆的存储库中的安全威胁。Git 功能强大，但它仍然只是一个计算机程序，因此要以人为本，确保每个人的安全。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/20/7/git-repos-best-practices
|
||||
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[stevenzdg988](https://github.com/stevenzdg988)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/seth
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/wfh_work_home_laptop_work.png?itok=VFwToeMy (Working from home at a laptop)
|
||||
[2]: https://securitylab.github.com/research/octopus-scanner-malware-open-source-supply-chain/
|
||||
[3]: https://opensource.com/sites/default/files/uploads/git_repo.png (Git repository )
|
||||
[4]: https://opensource.com/sites/default/files/uploads/git-binary-check.jpg (Git binary check)
|
||||
[5]: https://opensource.com/article/19/7/what-posix-richard-stallman-explains
|
||||
[6]: https://git-scm.com/book/en/v2/Git-Tools-Submodules
|
||||
[7]: https://opensource.com/sites/default/files/uploads/git-cola-manual-add.jpg (Git manual add)
|
||||
[8]: https://opensource.com/sites/default/files/uploads/git-ignore.jpg (Git ignore)
|
||||
[9]: https://github.com/github/gitignore
|
||||
[10]: https://about.gitlab.com/releases/2016/05/22/gitlab-8-8-released
|
||||
[11]: https://opensource.com/sites/default/files/uploads/git_merge_request.png (Git merge request)
|
||||
Loading…
Reference in New Issue
Block a user