使用GitHub的十个最佳实践

9.保护主分支，不要在其上直接提交代码

主分支中的任何内容都应该是可部署的，所以不应该直接在默认分支上提交代码，而且 Gitflow 工作流已成为标准。使用分支保护可以防止直接提交代码，当然，所有内容都应该通过 pr 进行管理。

8. 避免无法识别的提交

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

确保你的 Git 客户端配置了正确的电子邮件地址并链接到了你的 GitHub 用户。在代码审查期间检查你的 pr 是否存在无法识别的提交。

7. 为每个存储库定义 codeowners

使用 codeowners 功能可以定义哪些团队和人员被自动选为存储库的 reviewer。该功能会自动请求存储库 owner 进行审核。现在，组织动辄有数十个存储库，codeowners 可以从整个组织中选择定义 repo 的维护者。

6. 将源代码和 secret 凭证分离开

在构建 Cloud Native 应用时，我们保护了许多 secret - 帐户密码，API 密钥，私人令牌和 SSH 密钥。 千万不要将任何 secret 提交到代码中。可以使用从安全存储外部注入的环境变量。

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

有许多很棒的工具可以识别代码中现有的 secret 并防止出现新的 secret。例如，Git-secrets 可以帮助识别代码中的密码。使用 Git Hooks 可以构建一个预提交 hook 并检查每个 pr 的 secret。

5. 避免在项目中提交依赖

将依赖推到远程源将增加存储库大小。删除存储库中包含的所有项目依赖，并让包管理器在每个构建中下载它们。如果你担心“依赖的可用性”，你应该考虑使用 Jfrog 或 Nexus Repository 等二进制存储库管理器解决方案。查看 GitHub 的Git-Sizer。

4. 将源代码和配置文件分离开

强烈建议不要将本地配置文件提交到版本控制中。 通常，本地配置文件包含 secret，个人偏好，历史记录等私有配置文件，你是不会想将其推送到远程的。这些信息应当只保留在本地环境中。

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

每个存储库中都必须使用.gitignore 文件来忽略预定义的文件和目录。它将帮助你防止密码，依赖关系以及代码中许多其他可能的差异。可以从Gitignore.io中选择相关模板。

2. 归档不再维护的库

随着时间的推移，由于各种原因，我们的存储库可能已经无法维护了。也许你为一个临时用例打开了一个新的存储库（或者你想要 POC 一个新技术），或者你有一些包含旧的／不相关代码的存储库。 问题是相同的：这些存储库在达到目的之后不再被积极开发，你也不想再维护它们。最佳实践是归档这些存储库，设置为“只读”模式。

1. 锁住包版本

您的清单文件包含所有软件包版本的信息，以便在每次安装应用程序依赖项时保持一致的结果，不会破坏代码。最佳做法是使用清单锁定文件以避免任何差异，并确认每次都获得相同的软件包版本。 否则你的代码组件版本不精确，不确定将在下一个版本中安装哪个版本，并且代码可能会被破坏。

0. 对齐包版本

虽然你使用的是相同的软件包，但不同版本的发行版会使在各种项目中重用代码和测试变得更加困难。

如果你有一个在多个项目中使用的包，请至少尝试在不同的存储库中使用相同的主要版本。

原文链接：https://datree.io/blog/top-10-github-best-practices/