Github 十大最佳实践

59 阅读 0 评论 39 点赞

我是靠谱客的博主受伤铅笔，最近开发中收集的这篇文章主要介绍Github 十大最佳实践，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1、保护主分支不受直接提交的影响

主分支中的任何一次提交都应该是可以直接部署的，所以永远不要直接提交默认分支，同时也是 Gitflow workflow 成为标准的原因。使用分支保护可以帮你防止直接提交，当然，所有的事情都应该使用pull requests来管理。

2、避免基础信息的混乱

或许你在一个新的环境工作，或者你并没有注意到自己的 git 配置是不正确的，因此提交代码时伴随着错误的邮箱地址。如果提交没有关联到正确的用户信息，那将导致无法追溯到是谁写的代码。

保证你的 git 客户端配置是正确的邮箱地址，并且关联到你的 github 账户。评审代码时注意检查你的pull requests是否存在无法识别的提交。

3、为每个仓库定义 CODEOWNERS

使用 CODEOWNERS 功能可以定义哪些团队和人员被自动选为仓库的审阅者。此功能会自动请求仓库所有者进行审核。如今。组织拥有很多的仓库，而 CODEOWNERS 可以选择定义组织中的维护者。

4、从源代码中分离出秘密凭证

在构建云原生程序时，我们保护了许多的机密信息，比如账户密码、API 秘钥、私人令牌、SSH 秘钥等。绝对不要将任何机密信息提交到你的代码中，而应该采用从安全存储外部注入的环境变量。

你可以使用 Vault、AWS Secrets Manager 之类的工具来管理产品中的机密信息。

有很多超棒的工具可以识别代码中的机密信息，例如 Git-secrets 可以帮助你识别代码中的密码；使用 Git Hooks 可以构建一个预提交钩子，并检查每个pull requests中的机密信息。

5、不要提交项目的依赖

将项目的依赖提交到仓库中会增加仓库的大小。应该将你项目的所有依赖都从仓库中移除，让你的包管理器负责去下载它们。如果你担心“依赖可用性”，可以考虑使用 Jfrog 或 Nexus Repository 这样的二进制存储库管理器。

6、从源代码中分离配置文件

建议不要将本地配置文件提交到版本控制器，通常这些都是你不想推送到远程的私有配置文件，因为它们包含机密信息。个人的偏好，历史信息等应该保存在本地环境中。

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

每个仓库都必须使用.gitignore文件来忽略预定义的文件和目录，它可以帮助你保护代码中的机密信息、依赖项和其他可能的差异。你可以从 Gitignore.io 选择相关的模板。

8、将死库归档

随着时间的推移，由于各种原因，我们发现自已拥有不再维护的仓库。或许你为一个临时用例新建了仓库，或者有一些包含旧的和不相关代码的仓库。它们存在的问题是相同的，这些仓库在达到其目的之后不在被积极的维护开发，因此你不希望再维护它们或不希望其他人依赖/使用它们，最好的方式是将这些仓库归档，这样对每个人都是“只读”的。