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

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

8. 避免无法识别的提交

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

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

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

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

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

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

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

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

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

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

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

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

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