GitHub 怎么用？代码仓库、Pull Request 与 Actions

GitHub 主要解决哪些开发协作问题

个人项目可以从创建仓库、提交代码和写 README 开始；团队项目则要进一步约定分支、评审和 Issue 流程。公开仓库中的任何文件都应按公开信息处理。

GitHub 的核心不是“上传代码”，而是围绕仓库建立版本记录、Issue、Pull Request、Code Review 和自动化流程。即使是个人项目，也建议通过分支和 Pull Request 保留清晰的改动上下文。

从 github.com 创建一个不含敏感信息的测试仓库，完成一次提交、分支和 Pull Request。需要 GitHub Pages 时，再单独测试部署路径和自定义域名。

第一次使用可以从一个小仓库开始：提交 README、创建分支、发起一次 Pull Request，再尝试 Issue 和 Actions。把基本协作流程走通后，再决定是否需要更复杂的自动化。

不要把 API Key、密码、私钥或客户数据提交进仓库，即使之后删除也可能留在历史记录中。Actions 和第三方应用也应按最小权限配置。

仓库公开前要检查历史提交，不要只看当前文件。API Key、私钥或环境配置一旦进入 Git 历史，即使后来删除文件也可能继续存在，应立即撤销或轮换对应凭证。

如果需要更强的一体化 DevOps 或自托管路线，可以比较 GitLab；单纯代码托管则更应看团队已有生态和工作习惯。

GitHub 适合代码协作和开源生态；如果团队更依赖一体化 DevOps、自托管或不同的权限模型，可以再比较 GitLab。真正的迁移成本通常来自工作流和集成，而不是仓库文件本身。

个人项目可以边写边提交，但多人协作时最好提前约定分支、提交信息、Pull Request 和代码审查规则。规则不用复杂，关键是让团队知道“什么改动可以直接提交、什么改动必须经过审查、谁负责合并”。这样仓库历史才会真的有帮助，而不是只剩一堆难以理解的提交记录。

仓库里也要避免把密码、API Key、私钥和生产配置直接提交。即使后来删除，敏感信息也可能还存在于 Git 历史中。更稳妥的做法是从一开始就使用环境变量、Secrets 和忽略文件，并给高权限账号开启双重验证。

如果 GitHub 还承担 Pages、Actions 或发布流程，上线前最好模拟一次从新分支到合并、构建、部署和回滚的完整路径。只有开发和发布都能顺畅衔接，GitHub 才真正成为工作流中心，而不只是代码存放位置。