Translated by stevenzdg988

ONE

sources/tech/20200702 6 best practices for managing Git repos.md

@@ -7,38 +7,26 @@
 [#]: 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
 6 个最佳的 Git 仓库管理实践
 ======
-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]
 阻止向 Git 中添加内容的主张会使其变得更难管理；
 这里有替代方法。
 ![在家中使用笔记本电脑工作][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.
 有权访问源代码使对安全性的分析以及应用程序的安全成为可能。但是，如果没有人真正看过代码，问题就不会被发现，即使人们积极地看代码，通常也要看很多东西。幸运的是，GitHub 拥有一个活跃的安全团队，最近，他们 [发现了已提交到多个 Git 存储库中的特洛伊木马病毒][2]，甚至仓库的所有者也偷偷溜走了。尽管我们无法控制其他人如何管理自己的存储库，但我们可以从他们的错误中吸取教训。为此，本文回顾了将文件添加到自己的存储库中的一些最佳实践。
 
-### Know your repo
-了解您的仓库
+### 了解您的仓库
 
-![Git repository terminal][3]
 ![Git 存储库终端][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.
 对于安全的 Git 存储库来说大概是 Rule Zero (头号规则)。作为项目维护者，无论您是从自己的开始还是采用别人的，您的工作是了解自己存储库中的内容。您可能没有代码库中关于每个文件的存储列表，但是您需要了解所管理内容的基本组成。如果几十个合并后出现一个偏离的文件，您将可以很容易地识别它，因为您不知道它的用途，并且需要刷新内存检查它。发生这种情况时，请查看文件，并确保准确了解为什么它是必要的。
 
-### Ban binary blobs
-禁止二进制大文件
+### 禁止二进制大文件
 
-![Git binary check command in terminal][4]
 ![终端中 Git 的二进制检查命令][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.
-Git 用于文本，无论是用纯文本编写的 C 或 Python 还是 Java 文本，亦或是 JSON，YAML，XML，Markdown，HTML或类似的文本。Git 对于二进制文件不是很理想。
+Git 用于文本，无论是用纯文本编写的 C 或 Python 还是 Java 文本，亦或是 JSON，YAML，XML，Markdown，HTML 或类似的文本。Git 对于二进制文件不是很理想。
 
-It’s the difference between this:
 两者之间的区别是：
 
 ```
@@ -58,7 +46,6 @@ index f227cc3..0d85b44 100644
  Git knows how to version this.
 ```
 
-and this:
 和
 
 ```
@@ -77,13 +64,10 @@ IHDR7n<37>$gAMA<4D><41>
 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.
 更糟糕的是，Git 存储库维护者无法合理地审计二进制数据。这违反了 Rule Zero (头号规则)：应该对存储库的内容了如指掌。
 
-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:
 除了常用的 [POSIX(可移植性操作系统接口)][5] 工具之外，您还可以使用 `git diff` 检测二进制文件。当您尝试使用 `--numstat` 选项来比较二进制文件时，Git 返回空结果：
 
 ```
@@ -93,50 +77,36 @@ $ git diff --numstat /dev/null file.txt | tee
 5788  0   /dev/null =&gt; 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.
 如果您正在考虑将二进制大文件提交到存储库，请停下来先思考一下。如果是二进制文件，则它是由什么生成的。 有充分的理由在构建时生成它们来代替将它们提交存储库？你决定提交二进制数据可行，请确保在 README 文件或类似文件中标识二进制文件的位置，为什么是二进制的原因以及更新它们的协议。必须谨慎执行更新，因为对于提交给二进制大文件的每次更改，该二进制大文件的存储空间实际上都会加倍。
 
-### 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].
 第三方库也不例外。尽管它是开放源代码的众多优点之一，您可以不受限制地重用和重新分发未编写的代码，但是有很多充分的理由不去覆盖存储在您自己的存储库中第三方库。首先，除非您自己检查了所有代码（以及将来的合并），否则您无法准确确定第三方库。其次，当您将第三方库复制到您的 Git 存储库中时，会将焦点从真正的上游源分离出来。从技术上仅对主库的副本有把握，而不对随机存储库的副本有把握。如果您需要锁定特定版本的库，请为开发人员提供项目所需版本的合理 URL，或者使用[Git 子模块][6]。
 
-### Resist a blind git add
-抵制盲目的 `git add`
+### 抵制盲目的 `git add`
 
-![Git manual add command in terminal][7]
 ![Git 手动添加命令终端中][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.
 如果您的项目已编译，请不要使用 `git add .`（其中 `.` 是当前目录或特定文件夹的路径）作为添加任意和每一个新内容的简单方法。如果您不是手动编译项目，而是使用 IDE 为您管理项目，则这一点尤其重要。用 IDE 管理项目时，跟踪添加到存储库中的内容非常困难，因此仅添加您实际编写的内容非常重要，而不是在项目文件夹中弹出的任何新对象。
 
-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.
 如果您使用 `git add .` 做，请在推送之前检查这一状态里的情况。如果在执行 `git status` 时在项目文件夹中看到一个陌生的对象，请在运行 `make clean` 或等效命令找出它的来源以及为什么仍然在项目的目录中。这是非常好的不会在编译期间重新生成的创建方法，因此在提交前请三思。
 
-### Use Git ignore
-使用 Git ignore
+### 使用 Git ignore
 
 ![终端中的 `Git ignore` 命令][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.
 为程序员提供的许多方便的创建众说纷纭。任何项目，程序，富有艺术性的或其他的典型项目目录中都充斥着隐藏的文件，元数据和残留的内容。您可以尝试忽略这些对象，但是 `git status` 中的提示越多，您错过某件事的可能性就越大。
 
-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.
 您可以通过维护一个良好的 `gitignore` 文件来为您过滤掉这种噪音。因为这是使用 Git 的用户的共同要求，所以有一些入门 `gitignore` 文件可用。[Github.com/github/gitignore][9] 提供了几个专门创建 `gitignore` 的文件，您可以下载这些文件并将其放置到自己的项目中，几年前 [Gitlab.com][10] 将`gitignore` 模板集成到了存储库创建工作流程中。使用这些帮助您为项目创建适合的 `gitignore` 策略并遵守它。
 
-### Review merge requests
-查看合并请求
+### 查看合并请求
 
 ![Git 合并请求][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
-Git 责任
+### Git 责任
 
-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.
 社区致力于开源软件良好的安全性。不要鼓励在您的存储库中使用不良的 Git 实践，也不要忽视克隆的存储库中的安全威胁。Git 功能强大，但它仍然只是一个计算机程序，因此要以人为本，确保每个人的安全。
 
 --------------------------------------------------------------------------------