GitHub十大最佳实践

在扫描了数千个代码库并采访了数百名 GitHub 用户之后，我总结了一份通用最佳实践清单，强烈建议所有使用 GitHub 存储代码的现代软件开发组织都应采用这些实践：

9. 🚧 保护主分支免受直接提交的影响

主分支上的任何内容都应该始终可部署，这就是为什么永远不应该直接提交到默认分支，以及为什么Gitflow 工作流已成为标准的原因。使用分支保护可以帮助你防止直接提交，当然，所有操作都应该通过拉取请求来管理。

8. 👻 避免使用未识别的提交者

也许你正在使用新的环境，或者你没有注意到Git 配置有误，导致用户使用错误的电子邮件地址提交代码。现在，他们的提交与正确的用户不关联，几乎不可能追溯到是谁提交了什么。

请确保您的Git 客户端已配置正确的电子邮件地址并已关联到您的 GitHub 用户。在代码审查期间，检查您的拉取请求是否存在无法识别的提交。

7. 🎩 为每个仓库定义代码所有者

使用CODEOWNERS功能，您可以定义哪些团队和人员会被自动选为代码库的审阅者。此功能会自动向代码库所有者请求审阅。如今，许多组织拥有数十甚至数百个代码库，而 CODEOWNERS 功能允许您定义组织内哪些人员是代码库的维护者。

6. 🙊 将密钥凭证与源代码分离

构建云原生应用时，我们需要保护许多机密信息，例如账户密码、API 密钥、私钥和 SSH 密钥。切记！永远不要将任何机密信息直接提交到代码中。相反，应该使用从安全存储库外部注入的环境变量。

您可以使用Vault和AWS Secrets Manager等工具来帮助您在生产环境中进行密钥管理。

有很多优秀的工具可以帮助你识别代码中已有的秘密信息并防止出现新的秘密信息。例如，Git-secrets可以帮助你识别代码中的密码。借助Git Hooks，你可以创建一个pre-commit hook，并在每个 pull request 中检查是否存在秘密信息。

5. ⛔ 避免将依赖项提交到您的项目中

将依赖项推送到远程仓库会增加仓库大小。请移除仓库中包含的所有项目依赖项，并让包管理器在每次构建时下载它们。如果您担心“依赖项可用性”，则应考虑使用Jfrog或Nexus Repository等二进制仓库管理器解决方案。此外，还可以了解一下GitHub 的Git-Sizer 。

4. 🔧 将配置文件与源代码分离

我们强烈建议不要将本地配置文件提交到版本控制系统中。通常，这些是私有配置文件，您不希望将其推送到远程服务器，因为它们包含机密信息、个人偏好、历史记录或一般信息，这些信息应该仅保留在您的本地环境中。

📤 3. 为你的项目创建一个有意义的 .gitignore 文件

每个代码仓库都必须包含一个 .gitignore 文件，用于忽略预定义的文件和目录。它可以帮助您避免密钥、依赖项以及代码中可能存在的许多其他问题。您可以从Gitignore.io选择一个相关的模板。

2. 💀 归档失效的存储库

随着时间的推移，由于各种原因，我们会发现自己有一些代码仓库无人维护。也许你为了某个临时用例（或者你想验证一项新技术）而创建了一个新的仓库，又或许你有一些仓库里存放着过时且无关的代码。问题在于，这些仓库在完成其使命后就不再进行积极开发，因此你不想继续维护它们，以免其他人依赖或使用它们。最佳实践始终是将这些仓库归档，使其对所有人变为“只读”。

1. 🔒 锁定软件包版本

您的清单文件包含所有软件包的版本信息，以确保每次安装应用程序依赖项时都能获得一致的结果，避免代码出错。最佳实践是使用清单锁定文件来避免任何差异，并确保每次都获得相同的软件包版本。反之，如果您的代码组件版本信息不精确，则无法确定下次构建时将安装哪个版本，从而可能导致代码出错。

0. ♻️ 统一软件包版本控制

即使您使用的是同一个软件包，不同的版本分发方式也会使在各种项目中重用代码和测试变得更加困难。

如果你的软件包在多个项目中使用，至少要确保不同仓库中的主版本号相同。

🚀接下来是什么？

您剩下的工作就是将上述最佳实践逐一在您的每个代码库中进行核对。

或者，为了避免烦恼，您可以连接Datree 的 GitHub 应用（它是免费的！），扫描您的代码库并生成免费的状态报告，以评估您的代码库是否符合列出的最佳实践。