mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-03-27 02:30:10 +08:00
Merge remote-tracking branch 'LCTT/master'
This commit is contained in:
Xingyu Wang
commit
9df5a6e154
@ -1,8 +1,8 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (wxy)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11499-1.html)
|
||||
[#]: subject: (How writers can get work done better with Git)
|
||||
[#]: via: (https://opensource.com/article/19/4/write-git)
|
||||
[#]: author: (Seth Kenlon https://opensource.com/users/sethhttps://opensource.com/users/noreplyhttps://opensource.com/users/seth)
|
||||
@ -12,7 +12,7 @@
|
||||
|
||||
> 如果你是一名写作者，你也能从使用 Git 中受益。在我们的系列文章中了解有关 Git 鲜为人知的用法。
|
||||
|
||||
![Writing Hand][1]
|
||||
|
||||
|
||||
[Git][2] 是一个少有的能将如此多的现代计算封装到一个程序之中的应用程序，它可以用作许多其他应用程序的计算引擎。虽然它以跟踪软件开发中的源代码更改而闻名，但它还有许多其他用途，可以让你的生活更轻松、更有条理。在这个 Git 系列中，我们将分享七种鲜为人知的使用 Git 的方法。
|
||||
|
||||
@ -20,7 +20,7 @@
|
||||
|
||||
### 写作者的 Git
|
||||
|
||||
有些人写小说，也有人撰写学术论文、诗歌、剧本、技术手册或有关开源的文章。许多人都在做一点各种写作。相同的是，如果你是一名写作者，则或许能从使用 Git 中受益。尽管 Git 是著名的计算机程序员所使用的高度技术性工具，但它也是现代写作者的理想之选，本文将向你演示如何改变你的书写方式以及为什么要这么做的原因。
|
||||
有些人写小说，也有人撰写学术论文、诗歌、剧本、技术手册或有关开源的文章。许多人都在做一些各种写作。相同的是，如果你是一名写作者，或许能从使用 Git 中受益。尽管 Git 是著名的计算机程序员所使用的高度技术性工具，但它也是现代写作者的理想之选，本文将向你演示如何改变你的书写方式以及为什么要这么做的原因。
|
||||
|
||||
但是，在谈论 Git 之前，重要的是先谈谈“副本”（或者叫“内容”，对于数字时代而言）到底是什么，以及为什么它与你的交付*媒介*不同。这是 21 世纪，大多数写作者选择的工具是计算机。尽管计算机看似擅长将副本的编辑和布局等过程结合在一起，但写作者还是（重新）发现将内容与样式分开是一个好主意。这意味着你应该在计算机上像在打字机上而不是在文字处理器中进行书写。以计算机术语而言，这意味着以*纯文本*形式写作。
|
||||
|
||||
@ -30,13 +30,13 @@
|
||||
|
||||
你只需要逐字写下你的内容，而将交付工作留给发布者。即使你是自己发布，将字词作为写作作品的一种源代码也是一种更聪明、更有效的工作方式，因为在发布时，你可以使用相同的源（你的纯文本）生成适合你的目标输出（用于打印的 PDF、用于电子书的 EPUB、用于网站的 HTML 等）。
|
||||
|
||||
用纯文本编写不仅意味着你不必担心布局或文本样式，而且也不再需要专门的工具。无论是手机或平板电脑上的基本记事本应用程序、计算机附带的文本编辑器，还是从互联网上下载的免费编辑器，任何能够产生文本内容的工具对你而言都是有效的“文字处理器”。无论你身在何处或在做什么，几乎可以在任何设备上书写，并且所生成的文本可以与你的项目完美集成，而无需进行任何修改。
|
||||
用纯文本编写不仅意味着你不必担心布局或文本样式，而且也不再需要专门的工具。无论是手机或平板电脑上的基本的记事本应用程序、计算机附带的文本编辑器，还是从互联网上下载的免费编辑器，任何能够产生文本内容的工具对你而言都是有效的“文字处理器”。无论你身在何处或在做什么，几乎可以在任何设备上书写，并且所生成的文本可以与你的项目完美集成，而无需进行任何修改。
|
||||
|
||||
而且，Git 专门用来管理纯文本。
|
||||
|
||||
### Atom 编辑器
|
||||
|
||||
当你以纯文本形式书写时，文字处理程序会显得过于庞大。使用文本编辑器更容易，因为文本编辑器不会尝试“有效地”重组输入内容。它使你可以将脑海中的单词输入到屏幕中，而不会受到干扰。更好的是，文本编辑器通常是围绕插件体系结构设计的，这样应用程序本身就很基础（它用来编辑文本），但是你可以围绕它构建一个环境来满足你的各种需求。
|
||||
当你以纯文本形式书写时，文字处理程序会显得过于庞大。使用文本编辑器更容易，因为文本编辑器不会尝试“有效地”重组输入内容。它使你可以将脑海中的单词输入到屏幕中，而不会受到干扰。更好的是，文本编辑器通常是围绕插件体系结构设计的，这样应用程序本身很基础（它用来编辑文本），但是你可以围绕它构建一个环境来满足你的各种需求。
|
||||
|
||||
[Atom][4] 编辑器就是这种设计理念的一个很好的例子。这是一个具有内置 Git 集成的跨平台文本编辑器。如果你不熟悉纯文本格式，也不熟悉 Git，那么 Atom 是最简单的入门方法。
|
||||
|
||||
@ -64,15 +64,15 @@ Atom 当前没有在 BSD 上构建。但是，有很好的替代方法，例如
|
||||
|
||||
#### 快速指导
|
||||
|
||||
如果要使用纯文本和 Git，则需要适应你的编辑器。Atom 的用户界面可能比你习惯的更加动态。实际上，你可以将它视为 Firefox 或 Chrome，而不是文字处理程序，因为它具有可以根据需要打开和关闭的选项卡和面板，甚至还可以安装和配置附件。尝试全部掌握 Atom 如许之多的功能是不切实际的，但是你至少可以知道有什么功能。
|
||||
如果要使用纯文本和 Git，则需要适应你的编辑器。Atom 的用户界面可能比你习惯的更加动态。实际上，你可以将它视为 Firefox 或 Chrome，而不是文字处理程序，因为它具有可以根据需要打开或关闭的选项卡和面板，甚至还可以安装和配置附件。尝试全部掌握 Atom 如许之多的功能是不切实际的，但是你至少可以知道有什么功能。
|
||||
|
||||
当 Atom 打开时，它将显示一个欢迎屏幕。如果不出意外，此屏幕很好地介绍了 Atom 的选项卡式界面。你可以通过单击 Atom 窗口顶部选项卡上的“关闭”图标来关闭欢迎屏幕，并使用“文件 > 新建文件”创建一个新文件。
|
||||
当打开 Atom 时，它将显示一个欢迎屏幕。如果不出意外，此屏幕很好地介绍了 Atom 的选项卡式界面。你可以通过单击 Atom 窗口顶部选项卡上的“关闭”图标来关闭欢迎屏幕，并使用“文件 > 新建文件”创建一个新文件。
|
||||
|
||||
使用纯文本格式与使用文字处理程序有点不同，因此这里有一些技巧，以人可以连接的方式编写内容，并且 Git 和计算机可以解析，跟踪和转换。
|
||||
使用纯文本格式与使用文字处理程序有点不同，因此这里有一些技巧，以人可以理解的方式编写内容，并且 Git 和计算机可以解析，跟踪和转换。
|
||||
|
||||
#### 用 Markdown 书写
|
||||
|
||||
如今，当人们谈论纯文本时，大多是指 Markdown。Markdown 与其说是格式，不如说是样式，这意味着它旨在为文本提供可预测的结构，以便计算机可以检测自然的模式并智能地转换文本。Markdown 有很多定义，但是最好的技术定义和备忘单在 [CommonMark 的网站][8]上。
|
||||
如今，当人们谈论纯文本时，大多是指 Markdown。Markdown 与其说是格式，不如说是样式，这意味着它旨在为文本提供可预测的结构，以便计算机可以检测自然的模式并智能地转换文本。Markdown 有很多定义，但是最好的技术定义和备忘清单在 [CommonMark 的网站][8]上。
|
||||
|
||||
```
|
||||
# Chapter 1
|
||||
@ -85,9 +85,9 @@ And it can even reference an image.
|
||||
|
||||
从示例中可以看出，Markdown 读起来感觉不像代码，但可以将其视为代码。如果你遵循 CommonMark 定义的 Markdown 规范，那么一键就可以可靠地将 Markdown 的文字转换为 .docx、.epub、.html、MediaWiki、.odt、.pdf、.rtf 和各种其他的格式，而*不会*失去格式。
|
||||
|
||||
你可以认为 Markdown 有点像文字处理程序的样式。如果你曾经为出版社撰写过一套样式来控制章节标题和章节标题的样式，那基本上就是一回事，除了不是从下拉菜单中选择样式以外，你要给你的文字添加一些小记号。对于任何习惯“以文字交谈”的现代阅读者来说，这些表示法都是很自然的，但是在呈现文本时，它们会被精美的文本样式替换掉。实际上，这是文字处理程序在后台秘密进行的操作。文字处理器显示粗体文本，但是如果你可以看到使文本变为粗体的生成代码，则它与 Markdown 很像（实际上，它是更复杂的 XML）。使用 Markdown 可以消除这种代码和样式之间的阻隔，一方面看起来更可怕，但另一方面，你可以在几乎所有可以生成文本的东西上书写 Markdown 而不会丢失任何格式信息。
|
||||
你可以认为 Markdown 有点像文字处理程序的样式。如果你曾经为出版社撰写过一套样式来控制章节标题及其样式，那基本上就是一回事，除了不是从下拉菜单中选择样式以外，你需要给你的文字添加一些小记号。对于任何习惯“以文字交谈”的现代阅读者来说，这些表示法都是很自然的，但是在呈现文本时，它们会被精美的文本样式替换掉。实际上，这就是文字处理程序在后台秘密进行的操作。文字处理器显示粗体文本，但是如果你可以看到使文本变为粗体的生成代码，则它与 Markdown 很像（实际上，它是更复杂的 XML）。使用 Markdown 可以消除这种代码和样式之间的阻隔，一方面看起来更可怕一些，但另一方面，你可以在几乎所有可以生成文本的东西上书写 Markdown 而不会丢失任何格式信息。
|
||||
|
||||
Markdown 文件流行d 文件扩展名是 .md。如果你使用的平台不知道 .md 文件是什么，则可以手动将扩展名与 Atom 关联，或者仅使用通用的 .txt 扩展名。文件扩展名不会更改文件的性质。它只会改变你的计算机决定如何处理它的方式。Atom 和某些平台足够聪明，可以知道该文件是纯文本格式，无论你给它以什么扩展名。
|
||||
Markdown 文件流行的文件扩展名是 .md。如果你使用的平台不知道 .md 文件是什么，则可以手动将该扩展名与 Atom 关联，或者仅使用通用的 .txt 扩展名。文件扩展名不会更改文件的性质。它只会改变你的计算机决定如何处理它的方式。Atom 和某些平台足够聪明，可以知道该文件是纯文本格式，无论你给它以什么扩展名。
|
||||
|
||||
#### 实时预览
|
||||
|
||||
@ -97,25 +97,25 @@ Atom 具有 “Markdown 预览” 插件，该插件可以向你显示正在编
|
||||
|
||||
要激活此预览窗格，请选择“包 > Markdown 预览 > 切换预览” 或按 `Ctrl + Shift + M`。
|
||||
|
||||
此视图为你提供了两全其美的方法。无需承担为你的文本添加样式的负担，就可以写作，而你也可以看到一个通用的示例外观，至少是以典型的数字化格式显示了文本的外观。当然，关键是你无法控制文本的最终呈现方式，因此不要试图调整 Markdown 来强制以某种方式显示呈现的预览。
|
||||
此视图为你提供了两全其美的方法。无需承担为你的文本添加样式的负担就可以写作，而你也可以看到一个通用的示例外观，至少是以典型的数字化格式显示文本的外观。当然，关键是你无法控制文本的最终呈现方式，因此不要试图调整 Markdown 来强制以某种方式显示呈现的预览。
|
||||
|
||||
#### 每行一句话
|
||||
|
||||
你的高中写作老师不会看你的 Markdown。
|
||||
|
||||
一开始它并那么自然，但是在数字世界中，保持每行一个句子更有意义。Markdown 忽略单个换行符（当你按下 Return 或 Enter 键时），并且只在单个空行之后才会创建一个新段落。
|
||||
一开始它不那么自然，但是在数字世界中，保持每行一个句子更有意义。Markdown 会忽略单个换行符（当你按下 `Return` 或 `Enter` 键时），并且只在单个空行之后才会创建一个新段落。
|
||||
|
||||
![Writing in Atom][10]
|
||||
|
||||
每行写一个句子的好处是你的工作更容易跟踪。也就是说，如果你在段落的开头更改了一个单词，那么如果更改仅限于一行而不是一个长的段落中的一个单词，那么 Atom、Git 或任何应用程序很容易以有意义的方式突出显示该更改。换句话说，对一个句子的更改只会影响该句子，而不会影响整个段落。
|
||||
每行写一个句子的好处是你的工作更容易跟踪。也就是说，假如你在段落的开头更改了一个单词，如果更改仅限于一行而不是一个长的段落中的一个单词，那么 Atom、Git 或任何应用程序很容易以有意义的方式突出显示该更改。换句话说，对一个句子的更改只会影响该句子，而不会影响整个段落。
|
||||
|
||||
你可能会想：“许多文字处理器也可以跟踪更改，它们可以突出显示已更改的单个单词。”但是这些修订跟踪器绑定到该字处理器的界面上，这意味着你必须先打开该字处理器才能浏览修订。在纯文本工作流程中，你可以以纯文本形式查看修订，这意味着无论手头有什么，只要该设备可以处理纯文本（大多数都可以），就可以进行编辑或批准编辑。
|
||||
你可能会想：“许多文字处理器也可以跟踪更改，它们可以突出显示已更改的单个单词。”但是这些修订跟踪器绑定在该字处理器的界面上，这意味着你必须先打开该字处理器才能浏览修订。在纯文本工作流程中，你可以以纯文本形式查看修订，这意味着无论手头有什么，只要该设备可以处理纯文本（大多数都可以），就可以进行编辑或批准编辑。
|
||||
|
||||
诚然，写作者通常不会考虑行号，但它对于计算机有用，并且通常是一个很好的参考点。默认情况下，Atom 为文本文档的行进行编号。按下 Enter 键或 Return 键后，一*行*就是一行。
|
||||
诚然，写作者通常不会考虑行号，但它对于计算机有用，并且通常是一个很好的参考点。默认情况下，Atom 为文本文档的行进行编号。按下 `Enter` 键或 `Return` 键后，一*行*就是一行。
|
||||
|
||||
![Writing in Atom][11]
|
||||
|
||||
如果一行中有一个点而不是一个数字，则表示它是上一行折叠的一部分，因为它不超出了你的屏幕。
|
||||
如果（在 Atom 的）一行的行号中有一个点而不是一个数字，则表示它是上一行折叠的一部分，因为它超出了你的屏幕。
|
||||
|
||||
#### 主题
|
||||
|
||||
@ -127,7 +127,7 @@ Atom 具有 “Markdown 预览” 插件，该插件可以向你显示正在编
|
||||
|
||||
![Atom's themes][13]
|
||||
|
||||
要使用已安装的主题或根据喜好自定义主题，请导航至“设置”标签页中的“主题”类别中。从下拉菜单中选择要使用的主题。更改会立即进行，因此你可以准确了解主题如何影响您的环境。
|
||||
要使用已安装的主题或根据喜好自定义主题，请导航至“设置”标签页中的“主题”类别中。从下拉菜单中选择要使用的主题。更改会立即进行，因此你可以准确了解主题如何影响你的环境。
|
||||
|
||||
你也可以在“设置”标签的“编辑器”类别中更改工作字体。Atom 默认采用等宽字体，程序员通常首选这种字体。但是你可以使用系统上的任何字体，无论是衬线字体、无衬线字体、哥特式字体还是草书字体。无论你想整天盯着什么字体都行。
|
||||
|
||||
@ -139,19 +139,19 @@ Atom 具有 “Markdown 预览” 插件，该插件可以向你显示正在编
|
||||
|
||||
创建长文档时，我发现每个文件写一个章节比在一个文件中写整本书更有意义。此外，我不会以明显的语法 ` chapter-1.md` 或 `1.example.md` 来命名我的章节，而是以章节标题或关键词（例如 `example.md`）命名。为了将来为自己提供有关如何编写本书的指导，我维护了一个名为 `toc.md` （用于“目录”）的文件，其中列出了各章的（当前）顺序。
|
||||
|
||||
我这样做是因为，无论我多么相信第 6 章都不可能出现在第 1 章之前，但在我完成整本书之前，几乎不大可能出现我不会交换一两个章节的顺序。我发现从一开始就保持动态变化可以帮助我避免重命名混乱，也可以帮助我避免僵化的结构。
|
||||
我这样做是因为，无论我多么相信第 6 章都不可能出现在第 1 章之前，但在我完成整本书之前，几乎难以避免我会交换一两个章节的顺序。我发现从一开始就保持动态变化可以帮助我避免重命名混乱，也可以帮助我避免僵化的结构。
|
||||
|
||||
### 在 Atom 中使用 Git
|
||||
|
||||
每位写作者的共同点是两件事：他们为流传而写作，而他们的写作是一段旅程。你无需坐下来写作就完成最终稿件。顾名思义，你有一个初稿。该草稿会经过修订，你会仔细地将每个修订保存一式两份或三份，以防万一你的文件损坏了。最终，你得到了所谓的最终草案，但很有可能你有一天还会回到这份最终草案，要么恢复好的部分要么修改坏的部分。
|
||||
每位写作者的共同点是两件事：他们为流传而写作，而他们的写作是一段旅程。你不能一坐下来写作就完成了最终稿件。顾名思义，你有一个初稿。该草稿会经过修订，你会仔细地将每个修订保存一式两份或三份的备份，以防万一你的文件损坏了。最终，你得到了所谓的最终草稿，但很有可能你有一天还会回到这份最终草稿，要么恢复好的部分，要么修改坏的部分。
|
||||
|
||||
Atom 最令人兴奋的功能是其强大的 Git 集成。无需离开 Atom，你就可以与 Git 的所有主要功能进行交互，跟踪和更新项目、回滚你不喜欢的更改、集成来自协作者的更改等等。最好的学习方法就是逐步学习，因此这是从写作项目开始到结束在 Atom 界面中使用 Git 的方法。
|
||||
Atom 最令人兴奋的功能是其强大的 Git 集成。无需离开 Atom，你就可以与 Git 的所有主要功能进行交互，跟踪和更新项目、回滚你不喜欢的更改、集成来自协作者的更改等等。最好的学习方法就是逐步学习，因此这是在一个写作项目中从始至终在 Atom 界面中使用 Git 的方法。
|
||||
|
||||
第一件事：通过选择 “视图 > 切换 Git 标签页” 来显示 Git 面板。这将在 Atom 界面的右侧打开一个新标签页。现在没什么可看的，所以暂时保持打开状态就行。
|
||||
|
||||
#### 建立一个 Git 项目
|
||||
|
||||
你可以将 Git 视为它被绑定到文件夹。Git 目录之外的任何文件夹都不知道 Git，而 Git 也不知道外面。Git 目录中的文件夹和文件将被忽略，直到你授予 Git 权限来跟踪它们为止。
|
||||
你可以认为 Git 被绑定到一个文件夹。Git 目录之外的任何文件夹都不知道 Git，而 Git 也不知道外面。Git 目录中的文件夹和文件将被忽略，直到你授予 Git 权限来跟踪它们为止。
|
||||
|
||||
你可以通过在 Atom 中创建新的项目文件夹来创建 Git 项目。选择 “文件 > 添加项目文件夹”，然后在系统上创建一个新文件夹。你创建的文件夹将出现在 Atom 窗口的左侧“项目面板”中。
|
||||
|
||||
@ -159,11 +159,11 @@ Atom 最令人兴奋的功能是其强大的 Git 集成。无需离开 Atom，
|
||||
|
||||
右键单击你的新项目文件夹，然后选择“新建文件”以在项目文件夹中创建一个新文件。如果你要导入文件到新项目中，请右键单击该文件夹，然后选择“在文件管理器中显示”，以在系统的文件查看器中打开该文件夹（Linux 上为 Dolphin 或 Nautilus，Mac 上为 Finder，在 Windows 上是 Explorer），然后拖放文件到你的项目文件夹。
|
||||
|
||||
在 Atom 中打开一个项目文件（你创建的空文件或导入的文件）后，单击 Git 标签中的 “<ruby>创建存储库<rt>Create Repository</rt></ruby>” 按钮。在弹出的对话框中，单击 “<ruby>初始化<rt>Init</rt></ruby>” 以将你的项目目录初始化为本地 Git 存储库。 Git 会将 `.git` 目录（在系统的文件管理器中不可见，但在 Atom 中可见）添加到项目文件夹中。不要被这个愚弄了：`.git` 目录是 Git 管理的，而不是由你管理的，因此你一般不要动它。但是在 Atom 中看到它可以很好地提醒你正在由 Git 管理的项目中工作。换句话说，当你看到 `.git` 目录时，就有了修订历史记录。
|
||||
在 Atom 中打开一个项目文件（你创建的空文件或导入的文件）后，单击 Git 标签中的 “<ruby>创建存储库<rt>Create Repository</rt></ruby>” 按钮。在弹出的对话框中，单击 “<ruby>初始化<rt>Init</rt></ruby>” 以将你的项目目录初始化为本地 Git 存储库。 Git 会将 `.git` 目录（在系统的文件管理器中不可见，但在 Atom 中可见）添加到项目文件夹中。不要被这个愚弄了：`.git` 目录是 Git 管理的，而不是由你管理的，因此一般你不要动它。但是在 Atom 中看到它可以很好地提醒你正在由 Git 管理的项目中工作。换句话说，当你看到 `.git` 目录时，就有了修订历史记录。
|
||||
|
||||
在你的空文件中，写一些东西。你是写作者，所以输入一些单词就行。你可以随意输入任何一组单词，但要记住上面的写作技巧。
|
||||
|
||||
按 `Ctrl + S` 保存文件，该文件将显示在 Git 标签的 “<ruby>未暂存的改变<rt>Unstaged Changes</rt></ruby>” 部分中。这意味着该文件存在于你的项目文件夹中，但尚未提交给 Git 管理。通过单击 Git 选项卡右上方的 “<ruby>暂存全部<rt>Stage All</rt></ruby>” 按钮，允许 Git 跟踪这些文件。如果你使用过带有修订历史记录的文字处理器，则可以将此步骤视为允许 Git记录更改。
|
||||
按 `Ctrl + S` 保存文件，该文件将显示在 Git 标签的 “<ruby>未暂存的改变<rt>Unstaged Changes</rt></ruby>” 部分中。这意味着该文件存在于你的项目文件夹中，但尚未提交给 Git 管理。通过单击 Git 选项卡右上方的 “<ruby>暂存全部<rt>Stage All</rt></ruby>” 按钮，以允许 Git 跟踪这些文件。如果你使用过带有修订历史记录的文字处理器，则可以将此步骤视为允许 Git 记录更改。
|
||||
|
||||
#### Git 提交
|
||||
|
||||
@ -171,7 +171,7 @@ Atom 最令人兴奋的功能是其强大的 Git 集成。无需离开 Atom，
|
||||
|
||||
Git 的<ruby>提交<rt>commit</rt></ruby>会将你的文件发送到 Git 的内部和永久存档中。如果你习惯于文字处理程序，这就类似于给一个修订版命名。要创建一个提交，请在 Git 选项卡底部的“<ruby>提交<rt>Commit</rt></ruby>”消息框中输入一些描述性文本。你可能会感到含糊不清或随意写点什么，但如果你想在将来知道进行修订的原因，那么输入一些有用的信息会更有用。
|
||||
|
||||
第一次提交时，必须创建一个<ruby>分支<rt>branch</rt></ruby>。Git 分支有点像另外一个空间，它允许你从一个时间轴切换到另一个时间轴，以进行你可能想要或可能不想要永久保留的更改。如果最终喜欢该更改，则可以将一个实验分支合并到另一个实验分支，从而统一项目的不同版本。这是一个高级过程，不需要先学会，但是你仍然需要一个活动分支，因此你必须为首次提交创建一个分支。
|
||||
第一次提交时，必须创建一个<ruby>分支<rt>branch</rt></ruby>。Git 分支有点像另外一个空间，它允许你从一个时间轴切换到另一个时间轴，以进行你可能想要也可能不想要永久保留的更改。如果最终喜欢该更改，则可以将一个实验分支合并到另一个实验分支，从而统一项目的不同版本。这是一个高级过程，不需要先学会，但是你仍然需要一个活动分支，因此你必须为首次提交创建一个分支。
|
||||
|
||||
单击 Git 选项卡最底部的“<ruby>分支<rt>Branch</rt></ruby>”图标，以创建新的分支。
|
||||
|
||||
@ -185,7 +185,7 @@ Git 的<ruby>提交<rt>commit</rt></ruby>会将你的文件发送到 Git 的内
|
||||
|
||||
#### 历史记录和 Git 差异
|
||||
|
||||
一个自然而然的问题是你应该多久做一次提交。这并没有正确的答案。使用 `Ctrl + S` 保存文件并提交到 Git 是两个单独的过程，因此你会一直做这两个过程。每当你觉得自己已经做了重要的事情或打算尝试一个可能要被干掉的疯狂的新想法时，你可能都会想要做个提交。
|
||||
一个自然而然的问题是你应该多久做一次提交。这并没有正确的答案。使用 `Ctrl + S` 保存文件和提交到 Git 是两个单独的过程，因此你会一直做这两个过程。每当你觉得自己已经做了重要的事情或打算尝试一个可能会被干掉的疯狂的新想法时，你可能都会想要做次提交。
|
||||
|
||||
要了解提交对工作流程的影响，请从测试文档中删除一些文本，然后在顶部和底部添加一些文本。再次提交。 这样做几次，直到你在 Git 标签的底部有了一小段历史记录，然后单击其中一个提交以在 Atom 中查看它。
|
||||
|
||||
@ -199,15 +199,15 @@ Git 的<ruby>提交<rt>commit</rt></ruby>会将你的文件发送到 Git 的内
|
||||
|
||||
#### 远程备份
|
||||
|
||||
使用 Git 的优点之一是，按照设计，它是分布式的，这意味着你可以将工作提交到本地存储库，并将所做的更改推送到任意数量的服务器上进行备份。你还可以从这些服务器中拉取更改，以便你碰巧正在使用的任何设备始终具有最新更改。
|
||||
使用 Git 的优点之一是，按照设计它是分布式的，这意味着你可以将工作提交到本地存储库，并将所做的更改推送到任意数量的服务器上进行备份。你还可以从这些服务器中拉取更改，以便你碰巧正在使用的任何设备始终具有最新更改。
|
||||
|
||||
为此，你必须在 Git 服务器上拥有一个帐户。有几种免费的托管服务，其中包括 GitHub，这个公司开发了 Atom，但奇怪的是 GitHub 不是开源的；而 GitLab 是开源的。相比私有的，我更喜欢开源，在本示例中，我将使用 GitLab。
|
||||
为此，你必须在 Git 服务器上拥有一个帐户。有几种免费的托管服务，其中包括 GitHub，这个公司开发了 Atom，但奇怪的是 GitHub 不是开源的；而 GitLab 是开源的。相比私有软件，我更喜欢开源，在本示例中，我将使用 GitLab。
|
||||
|
||||
如果你还没有 GitLab 帐户，请注册一个帐户并开始一个新项目。项目名称不必与 Atom 中的项目文件夹匹配，但是如果匹配，则可能更有意义。你可以将项目保留为私有，在这种情况下，只有你和任何一个你给予了明确权限的人可以访问它，或者，如果你希望该项目可供任何互联网上偶然发现它的人使用，则可以将其公开。
|
||||
|
||||
不要将 README 文件添加到项目中。
|
||||
|
||||
创建项目后，这个文件将为你提供有关如何设置存储库的说明。如果你决定在终端中或通过单独的 GUI 使用 Git，这是非常有用的信息，但是 Atom 的工作流程则有所不同。
|
||||
创建项目后，它将为你提供有关如何设置存储库的说明。如果你决定在终端中或通过单独的 GUI 使用 Git，这是非常有用的信息，但是 Atom 的工作流程则有所不同。
|
||||
|
||||
单击 GitLab 界面右上方的 “<ruby>克隆<rt>Clone</rt></ruby>” 按钮。这显示了访问 Git 存储库必须使用的地址。复制 “SSH” 地址（而不是 “https” 地址）。
|
||||
|
||||
@ -224,7 +224,7 @@ Git 的<ruby>提交<rt>commit</rt></ruby>会将你的文件发送到 Git 的内
|
||||
|
||||
在 Git 标签的底部，出现了一个新按钮，标记为 “<ruby>提取<rt>Fetch</rt></ruby>”。由于你的服务器是全新的服务器，因此没有可供你提取的数据，因此请右键单击该按钮，然后选择“<ruby>推送<rt>Push</rt></ruby>”。这会将你的更改推送到你的 GitLab 帐户，现在你的项目已备份到 Git 服务器上。
|
||||
|
||||
你可以在每次提交后将更改推送到服务器。它提供了立即的异地备份，并且由于数据量通常很少，因此它几乎与本地保存一样快。
|
||||
你可以在每次提交后将更改推送到服务器。它提供了即刻的异地备份，并且由于数据量通常很少，因此它几乎与本地保存一样快。
|
||||
|
||||
### 撰写而 Git
|
||||
|
||||
@ -237,7 +237,7 @@ via: https://opensource.com/article/19/4/write-git
|
||||
作者：[Seth Kenlon][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[wxy](https://github.com/wxy)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
@ -1,22 +1,24 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (hopefully2333)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: reviewer: (wxy)
|
||||
[#]: publisher: (wxy)
|
||||
[#]: url: (https://linux.cn/article-11498-1.html)
|
||||
[#]: subject: (How DevOps professionals can become security champions)
|
||||
[#]: via: (https://opensource.com/article/19/9/devops-security-champions)
|
||||
[#]: author: (Jessica Repka https://opensource.com/users/jrepkahttps://opensource.com/users/jrepkahttps://opensource.com/users/patrickhousleyhttps://opensource.com/users/mehulrajputhttps://opensource.com/users/alanfdosshttps://opensource.com/users/marcobravo)
|
||||
[#]: author: (Jessica Repka https://opensource.com/users/jrepka)
|
||||
|
||||
DevOps 专业人员如何成为网络安全拥护者
|
||||
======
|
||||
打破信息孤岛，成为网络安全的拥护者，这对你、对你的职业、对你的公司都会有所帮助。
|
||||
![A lock on the side of a building][1]
|
||||
|
||||
> 打破信息孤岛，成为网络安全的拥护者，这对你、对你的职业、对你的公司都会有所帮助。
|
||||
|
||||
|
||||
|
||||
安全是 DevOps 中一个被误解了的部分，一些人认为它不在 DevOps 的范围内，而另一些人认为它太过重要（并且被忽视），建议改为使用 DevSecOps。无论你同意哪一方的观点，网络安全都会影响到我们每一个人，这是很明显的事实。
|
||||
|
||||
每年, [黑客行为的统计数据][3] 都会更加令人震惊。例如, 每 39 秒就有一次黑客行为发生，这可能会导致你为公司写的记录、身份和专有项目被盗。你的安全团队可能需要花上几个月（也可能是永远找不到）才能发现这次黑客行为背后是谁，目的是什么，人在哪，什么时候黑进来的。
|
||||
每年，[黑客行为的统计数据][3] 都会更加令人震惊。例如，每 39 秒就有一次黑客行为发生，这可能会导致你为公司写的记录、身份和专有项目被盗。你的安全团队可能需要花上几个月（也可能是永远找不到）才能发现这次黑客行为背后是谁，目的是什么，人在哪，什么时候黑进来的。
|
||||
|
||||
运营专家面对这些棘手问题应该如何是好？呐我说，现在是时候成为网络安全的拥护者，变为解决方案的一部分了。
|
||||
运维专家面对这些棘手问题应该如何是好？呐我说，现在是时候成为网络安全的拥护者，变为解决方案的一部分了。
|
||||
|
||||
### 孤岛势力范围的战争
|
||||
|
||||
@ -28,52 +30,44 @@ DevOps 专业人员如何成为网络安全拥护者
|
||||
|
||||
为了打破这些孤岛并结束势力战争，我在每个安全团队中都选了至少一个人来交谈，了解我们组织日常安全运营里的来龙去脉。我开始做这件事是出于好奇，但我持续做这件事是因为它总是能带给我一些有价值的、新的观点。例如，我了解到，对于每个因为失败的安全性而被停止的部署，安全团队都在疯狂地尝试修复 10 个他们看见的其他问题。他们反应的莽撞和尖锐是因为他们必须在有限的时间里修复这些问题，不然这些问题就会变成一个大问题。
|
||||
|
||||
考虑到发现、识别和撤销已完成操作所需的大量知识，或者指出 DevOps 团队正在做什么-没有背景信息-然后复制并测试它。所有的这些通常都要由人手配备非常不足的安全团队完成。
|
||||
考虑到发现、识别和撤销已完成操作所需的大量知识，或者指出 DevOps 团队正在做什么（没有背景信息）然后复制并测试它。所有的这些通常都要由人手配备非常不足的安全团队完成。
|
||||
|
||||
这就是你的安全团队的日常生活，并且你的 DevOps 团队看不到这些。ITSEC 的日常工作意味着超时加班和过度劳累，以确保公司，公司的团队，团队里工作的所有人能够安全地工作。
|
||||
|
||||
### 成为安全拥护者的方法
|
||||
|
||||
这些是你成为你的安全团队的拥护者之后可以帮到它们的。这意味着-对于你做的所有操作-你必须仔细、认真地查看所有能够让其他人登录的方式，以及他们能够从中获得什么。
|
||||
这些是你成为你的安全团队的拥护者之后可以帮到它们的。这意味着，对于你做的所有操作，你必须仔细、认真地查看所有能够让其他人登录的方式，以及他们能够从中获得什么。
|
||||
|
||||
帮助你的安全团队就是在帮助你自己。将工具添加到你的工作流程里，以此将你知道的要干的活和他们知道的要干的活结合到一起。从小事入手，例如阅读公共漏洞披露（CVEs），并将扫描模块添加到你的 CI/CD 流程里。对于你写的所有代码，都会有一个开源扫描工具，添加小型开源工具（例如下面列出来的）在长远看来是可以让项目更好的。
|
||||
帮助你的安全团队就是在帮助你自己。将工具添加到你的工作流程里，以此将你知道的要干的活和他们知道的要干的活结合到一起。从小事入手，例如阅读公共漏洞披露（CVE），并将扫描模块添加到你的 CI/CD 流程里。对于你写的所有代码，都会有一个开源扫描工具，添加小型开源工具（例如下面列出来的）在长远看来是可以让项目更好的。
|
||||
|
||||
**容器扫描工具:**
|
||||
**容器扫描工具：**
|
||||
|
||||
* [Anchore Engine][5]
|
||||
* [Clair][6]
|
||||
* [Vuls][7]
|
||||
* [OpenSCAP][8]
|
||||
|
||||
|
||||
|
||||
**代码扫描工具:**
|
||||
**代码扫描工具：**
|
||||
|
||||
* [OWASP SonarQube][9]
|
||||
* [Find Security Bugs][10]
|
||||
* [Google Hacking Diggity Project][11]
|
||||
|
||||
|
||||
|
||||
**Kubernetes 安全工具:**
|
||||
**Kubernetes 安全工具：**
|
||||
|
||||
* [Project Calico][12]
|
||||
* [Kube-hunter][13]
|
||||
* [NeuVector][14]
|
||||
|
||||
|
||||
|
||||
### 保持你的 DevOps 态度
|
||||
|
||||
如果你的工作角色是和 DevOps 相关的，那么学习新技术和如何运用这项新技术创造新事物就是你工作的一部分。安全也是一样。我在 DevOps 安全方面保持到最新，下面是我的方法的列表。
|
||||
|
||||
* 每周阅读一篇你工作的方向里和安全相关的文章.
|
||||
* 每周查看 [CVE][15] 官方网站，了解出现了什么新漏洞.
|
||||
* 每周查看 [CVE][15] 官方网站，了解出现了什么新漏洞.
|
||||
* 尝试做一次黑客马拉松。一些公司每个月都要这样做一次；如果你觉得还不够、想了解更多，可以访问 Beginner Hack 1.0 网站。
|
||||
* 每年至少一次和那你的安全团队的成员一起参加安全会议，从他们的角度来看事情。
|
||||
|
||||
|
||||
|
||||
### 成为拥护者是为了变得更好
|
||||
|
||||
你应该成为你的安全的拥护者，下面是我们列出来的几个理由。首先是增长你的知识，帮助你的职业发展。第二是帮助其他的团队，培养新的关系，打破对你的组织有害的孤岛。在你的整个组织内建立由很多好处，包括设置沟通团队的典范，并鼓励人们一起工作。你同样能促进在整个组织中分享知识，并给每个人提供一个在安全方面更好的内部合作的新契机。
|
||||
@ -87,11 +81,11 @@ via: https://opensource.com/article/19/9/devops-security-champions
|
||||
作者：[Jessica Repka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[hopefully2333](https://github.com/hopefully2333)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
校对：[wxy](https://github.com/wxy)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/jrepkahttps://opensource.com/users/jrepkahttps://opensource.com/users/patrickhousleyhttps://opensource.com/users/mehulrajputhttps://opensource.com/users/alanfdosshttps://opensource.com/users/marcobravo
|
||||
[a]: https://opensource.com/users/jrepka
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/BUSINESS_3reasons.png?itok=k6F3-BqA (A lock on the side of a building)
|
||||
[2]: https://opensource.com/article/19/1/what-devsecops
|
||||
@ -0,0 +1,94 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (MX Linux 19 Released With Debian 10.1 ‘Buster’ & Other Improvements)
|
||||
[#]: via: (https://itsfoss.com/mx-linux-19/)
|
||||
[#]: author: (Ankush Das https://itsfoss.com/author/ankush/)
|
||||
|
||||
MX Linux 19 Released With Debian 10.1 ‘Buster’ & Other Improvements
|
||||
======
|
||||
|
||||
MX Linux 18 has been one of my top recommendations for the [best Linux distributions][1], specially when considering distros other than Ubuntu.
|
||||
|
||||
It is based on Debian 9.6 ‘Stretch’ – which was incredibly a fast and smooth experience.
|
||||
|
||||
Now, as a major upgrade to that, MX Linux 19 brings a lot of major improvements and changes. Here, we shall take a look at the key highlights.
|
||||
|
||||
### New features in MX Linux 19
|
||||
|
||||
[Subscribe to our YouTube channel for more Linux videos][2]
|
||||
|
||||
#### Debian 10 ‘Buster’
|
||||
|
||||
This deserves a separate mention as Debian 10 is indeed a major upgrade from Debian 9.6 ‘Stretch’ on which MX Linux 18 was based on.
|
||||
|
||||
In case you’re curious about what has changed with Debian 10 Buster, we suggest to check out our article on the [new features of Debian 10 Buster][3].
|
||||
|
||||
#### Xfce Desktop 4.14
|
||||
|
||||
![MX Linux 19][4]
|
||||
|
||||
[Xfce 4.14][5] happens to be the latest offering from Xfce development team. Personally, I’m not a fan of Xfce desktop environment but it screams fast performance when you get to use it on a Linux distro (especially on MX Linux 19).
|
||||
|
||||
Interestingly, we also have a quick guide to help you [customize Xfce][6] on your system.
|
||||
|
||||
#### Updated Packages & Latest Debian Kernel 4.19
|
||||
|
||||
Along with updated packages for [GIMP][7], MESA, Firefox, and so on – it also comes baked in with the latest kernel 4.19 available for Debian Buster.
|
||||
|
||||
#### Updated MX-Apps
|
||||
|
||||
If you’ve used MX Linux before, you might be knowing that it comes pre-installed with useful MX-Apps that help you get more things done quickly.
|
||||
|
||||
The apps like MX-installer and MX-packageinstaller have significantly improved.
|
||||
|
||||
In addition to these two, all other MX-tools have been updated here and there to fix bugs, add new translations (or simply to improve the user experience).
|
||||
|
||||
#### Other Improvements
|
||||
|
||||
Considering it a major upgrade, there’s obviously a lot of under-the-hood changes than highlighted (including the latest antiX live system updates).
|
||||
|
||||
You can check out more details on their [official announcement post][8]. You may also watch this video from the developers explaining all the new stuff in MX Linux 19:
|
||||
|
||||
### Getting MX Linux 19
|
||||
|
||||
Even if you are using MX Linux 18 versions right now, you [cannot upgrade][9] to MX Linux 19. You need to go for a clean install like everyone else.
|
||||
|
||||
You can download MX Linux 19 from this page:
|
||||
|
||||
[Download MX Linux 19][10]
|
||||
|
||||
**Wrapping Up**
|
||||
|
||||
With MX Linux 18, I had a problem using my WiFi adapter due to a driver issue which I resolved through the [forum][11], it seems that it still hasn’t been fixed with MX Linux 19. So, you might want to take a look at my [forum post][11] if you face the same issue after installing MX Linux 19.
|
||||
|
||||
If you’ve been using MX Linux 18, this definitely seems to be an impressive upgrade.
|
||||
|
||||
Have you tried it yet? What are your thoughts on the new MX Linux 19 release? Let me know what you think in the comments below.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://itsfoss.com/mx-linux-19/
|
||||
|
||||
作者：[Ankush Das][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://itsfoss.com/author/ankush/
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://itsfoss.com/best-linux-distributions/
|
||||
[2]: https://www.youtube.com/c/itsfoss?sub_confirmation=1
|
||||
[3]: https://itsfoss.com/debian-10-buster/
|
||||
[4]: https://i0.wp.com/itsfoss.com/wp-content/uploads/2019/10/mx-linux-19.jpg?ssl=1
|
||||
[5]: https://xfce.org/about/news
|
||||
[6]: https://itsfoss.com/customize-xfce/
|
||||
[7]: https://itsfoss.com/gimp-2-10-release/
|
||||
[8]: https://mxlinux.org/blog/mx-19-patito-feo-released/
|
||||
[9]: https://mxlinux.org/migration/
|
||||
[10]: https://mxlinux.org/download-links/
|
||||
[11]: https://forum.mxlinux.org/viewtopic.php?t=52201
|
||||
@ -1,101 +0,0 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Pylint: Making your Python code consistent)
|
||||
[#]: via: (https://opensource.com/article/19/10/python-pylint-introduction)
|
||||
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
|
||||
|
||||
Pylint: Making your Python code consistent
|
||||
======
|
||||
Pylint is your friend when you want to avoid arguing about code
|
||||
complexity.
|
||||
![OpenStack source code \(Python\) in VIM][1]
|
||||
|
||||
Pylint is a higher-level Python style enforcer. While [flake8][2] and [black][3] will take care of "local" style: where the newlines occur, how comments are formatted, or find issues like commented out code or bad practices in log formatting.
|
||||
|
||||
Pylint is extremely aggressive by default. It will offer strong opinions on everything from checking if declared interfaces are actually implemented to opportunities to refactor duplicate code, which can be a lot to a new user. One way of introducing it gently to a project, or a team, is to start by turning _all_ checkers off, and then enabling checkers one by one. This is especially useful if you already use flake8, black, and [mypy][4]: Pylint has quite a few checkers that overlap in functionality.
|
||||
|
||||
However, one of the things unique to Pylint is the ability to enforce higher-level issues: for example, number of lines in a function, or number of methods in a class.
|
||||
|
||||
These numbers might be different from project to project and can depend on the development team's preferences. However, once the team comes to an agreement about the parameters, it is useful to _enforce_ those parameters using an automated tool. This is where Pylint shines.
|
||||
|
||||
### Configuring Pylint
|
||||
|
||||
In order to start with an empty configuration, start your `.pylintrc` with
|
||||
|
||||
|
||||
```
|
||||
[MESSAGES CONTROL]
|
||||
|
||||
disable=all
|
||||
```
|
||||
|
||||
This disables all Pylint messages. Since many of them are redundant, this makes sense. In Pylint, a `message` is a specific kind of warning.
|
||||
|
||||
You can check that all messages have been turned off by running `pylint`:
|
||||
|
||||
|
||||
```
|
||||
`$ pylint <my package>`
|
||||
```
|
||||
|
||||
In general, it is not a great idea to add parameters to the `pylint` command-line: the best place to configure your `pylint` is the `.pylintrc`. In order to have it do _something_ useful, we need to enable some messages.
|
||||
|
||||
In order to enable messages, add to your `.pylintrc`, under the `[MESSAGES CONTROL]`.
|
||||
|
||||
|
||||
```
|
||||
enable=<message>,
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
For the "messages" (what Pylint calls different kinds of warnings) that look useful. Some of my favorites include `too-many-lines`, `too-many-arguments`, and `too-many-branches`. All of those limit complexity of modules or functions, and serve as an objective check, without a human nitpicker needed, for code complexity measurement.
|
||||
|
||||
A _checker_ is a source of _messages_: every message belongs to exactly one checker. Many of the most useful messages are under the [design checker][5]. The default numbers are usually good, but tweaking the maximums is straightfoward: we can add a section called `DESIGN` in the `.pylintrc`.
|
||||
|
||||
|
||||
```
|
||||
[DESIGN]
|
||||
|
||||
max-args=7
|
||||
|
||||
max-locals=15
|
||||
```
|
||||
|
||||
Another good source of useful messages is the `refactoring` checker. Some of my favorite messages to enable there are `consider-using-dict-comprehension`, `stop-iteration-return` (which looks for generators which use `raise StopIteration` when `return` is the correct way to stop the iteration). and `chained-comparison`, which will suggest using syntax like `1 <= x < 5` rather than the less obvious `1 <= x && 5 > 5`
|
||||
|
||||
Finally, an expensive checker, in terms of performance, but highly useful, is `similarities`. It is designed to enforce "Don't Repeat Yourself" (the DRY principle) by explicitly looking for copy-paste between different parts of the code. It only has one message to enable: `duplicate-code`. The default "minimum similarity lines" is set to `4`. It is possible to set it to a different value using the `.pylintrc`.
|
||||
|
||||
|
||||
```
|
||||
[SIMILARITIES]
|
||||
|
||||
min-similarity-lines=3
|
||||
```
|
||||
|
||||
### Pylint makes code reviews easy
|
||||
|
||||
If you are sick of code reviews where you point out that a class is too complicated, or that two different functions are basically the same, add Pylint to your [Continuous Integration][6] configuration, and only have the arguments about complexity guidelines for your project _once_.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/10/python-pylint-introduction
|
||||
|
||||
作者：[Moshe Zadka][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/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/openstack_python_vim_2.jpg?itok=4fza48WU (OpenStack source code (Python) in VIM)
|
||||
[2]: https://opensource.com/article/19/5/python-flake8
|
||||
[3]: https://opensource.com/article/19/5/python-black
|
||||
[4]: https://opensource.com/article/19/5/python-mypy
|
||||
[5]: https://pylint.readthedocs.io/en/latest/technical_reference/features.html#design-checker
|
||||
[6]: https://opensource.com/business/15/7/six-continuous-integration-tools
|
||||
@ -1,5 +1,5 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: ( )
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
|
||||
@ -0,0 +1,99 @@
|
||||
[#]: collector: (lujun9972)
|
||||
[#]: translator: (geekpi)
|
||||
[#]: reviewer: ( )
|
||||
[#]: publisher: ( )
|
||||
[#]: url: ( )
|
||||
[#]: subject: (Pylint: Making your Python code consistent)
|
||||
[#]: via: (https://opensource.com/article/19/10/python-pylint-introduction)
|
||||
[#]: author: (Moshe Zadka https://opensource.com/users/moshez)
|
||||
|
||||
Pylint：让你的 Python 代码保持一致
|
||||
======
|
||||
当你想要争论代码复杂性时，Pylint 是你的朋友。
|
||||
![OpenStack source code \(Python\) in VIM][1]
|
||||
|
||||
Pylint 是更高层级的 Python 样式强制程序。而 [flake8][2] 和 [black][3] 检查的是“本地”样式：换行位置、注释的格式、发现注释掉的代码或日志格式中的错误做法之类的问题。
|
||||
|
||||
默认情况下，Pylint 非常激进。它将对一切提供强有力的意见，从检查是否实际实现声明的接口到重构重复代码，这对新用户来说可能会很多。一种温和地将其引入项目或团对的方法是先关闭_所有_检查器，然后逐个启用检查器。如果你已经在使用 flake8、black 和 [mypy][4]，这尤其有用：Pylint 有相当多的检查器在功能上重叠。
|
||||
|
||||
但是，Pylint 独有之处之一是能够强制执行更高级别的问题：例如，函数的行数或者类中方法的数量。
|
||||
|
||||
这些数字可能因项目而异，并且可能取决于开发团队的偏好。但是，一旦团队就参数达成一致，使用自动工具_强制化_这些参数非常有用。这是 Pylint 闪耀的地方。
|
||||
|
||||
### 配置 Pylint
|
||||
|
||||
要以空配置开始，请将 `.pylintrc` 设置为
|
||||
|
||||
|
||||
```
|
||||
[MESSAGES CONTROL]
|
||||
|
||||
disable=all
|
||||
```
|
||||
|
||||
这将禁用所有 Pylint 消息。由于其中许多是冗余的，这是有道理的。在 Pylint 中， `message` 是一种特定的警告。
|
||||
|
||||
你可以通过运行 `pylint` 来检查所有消息都已关闭：
|
||||
|
||||
|
||||
```
|
||||
`$ pylint <my package>`
|
||||
```
|
||||
|
||||
通常，向 `pylint` 命令行添加参数并不是一个好主意：配置 `pylint` 的最佳位置是 `.pylintrc`。为了使它做_一些_有用的事，我们需要启用一些消息。
|
||||
|
||||
要启用消息，在 `.pylintrc` 中的 `[MESSAGES CONTROL]` 下添加
|
||||
|
||||
|
||||
```
|
||||
enable=<message>,
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
对于看起来有用的“消息”（Pylint 称之为不同类型的警告）。我最喜欢的包括 `too-many-lines`、`too-many-arguments` 和 `too-many-branches`。所有这些限制模块或函数的复杂性，并且无需进行人工操作即可客观地进行代码复杂度测量。。
|
||||
|
||||
_检查器_是_消息_的来源：每条消息只属于一个检查器。许多最有用的消息都在[设计检查器][5]下。 默认数字通常都不错，但要调整最大值也很简单：我们可以在 `.pylintrc` 中添加一个名为 `DESIGN` 的一段。
|
||||
|
||||
|
||||
```
|
||||
[DESIGN]
|
||||
|
||||
max-args=7
|
||||
|
||||
max-locals=15
|
||||
```
|
||||
|
||||
另一个有用的消息来源是`重构`检查器。我已启用一些最喜欢的消息有 `consider-using-dict-comprehension`、`stop-iteration-return`（它会查找使用当 `return` 是正确的停止迭代的方式，而使用 `raise StopIteration` 的迭代器）和 `chained-comparison`，它将建议使用如 `1 <= x < 5`，而不是不太明显的 `1 <= x && 5 > 5` 的语法
|
||||
|
||||
最后是一个在性能方面昂贵的检查器，但它非常有用，是 `similarities`。它会查找不同部分代码之间的复制粘贴来强制执行“不要重复自己”（DRY 原则）。它只启用一条消息：`duplicate-code`。默认的 “minimum similarity lines” 设置为 “4”。可以使用 `.pylintrc` 将其设置为不同的值。
|
||||
|
||||
```
|
||||
[SIMILARITIES]
|
||||
|
||||
min-similarity-lines=3
|
||||
```
|
||||
|
||||
### Pylint 使代码评审变得简单
|
||||
|
||||
如果你厌倦了需要指出一个类太复杂，或者两个不同的函数基本相同的代码评审，请将 Pylint 添加到你的[持续集成][6]配置中，只需_一次性_设置你项目的复杂性指导参数。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/19/10/python-pylint-introduction
|
||||
|
||||
作者：[Moshe Zadka][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/moshez
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/openstack_python_vim_2.jpg?itok=4fza48WU (OpenStack source code (Python) in VIM)
|
||||
[2]: https://opensource.com/article/19/5/python-flake8
|
||||
[3]: https://opensource.com/article/19/5/python-black
|
||||
[4]: https://opensource.com/article/19/5/python-mypy
|
||||
[5]: https://pylint.readthedocs.io/en/latest/technical_reference/features.html#design-checker
|
||||
[6]: https://opensource.com/business/15/7/six-continuous-integration-tools
|
||||
Loading…
Reference in New Issue
Block a user