GitHub

接入 GitHub（第三方登录或调用 API）主要依赖 OAuth 2.0 授权协议。通过接入 GitHub，开发者可以实现“用 GitHub 账号一键登录平台”以及“获取用户公开信息、仓库数据”等功能。 1. 接入前的准备：创建 OAuth App 在开始写代码前，必须先在 GitHub 注册一个 OAuth Application。 登录 GitHub，点击右上角头像 -> Settings（设置）。 在左侧边栏最下方，点击 Developer settings（开发者设置）。 选择 OAuth Apps，点击 New OAuth App（或 Register a new application）。 填写应用信息： Application name：应用名称（如 MyApp）。 Homepage URL：应用主页地址（本地测试可填 http://localhost:3000）。 Authorization callback URL：核心字段，授权成功后的回调地址（如 http://localhost:3000/api/v1/auth/callback/github）。 点击 Register application 完成注册。 注册完成后，系统会生成： Client ID：应用的公开唯一标识。 Client Secret：密钥，点击 Generate a new client secret 生成（切记妥善保管，严禁暴露在前端）。 官方参考文档：Creating an OAuth app - GitHub Docs 2. GitHub OAuth 2....

GitHub 不只是代码托管平台 很多开发者使用 GitHub 时，主要把它当成远程 Git 仓库： git push ↓ GitHub 但对于一个真正需要长期维护的项目来说，代码仓库只是 GitHub 的一部分。 一个完整的软件开发过程通常还包括： 需求 ↓ Issue ↓ 开发 ↓ Pull Request ↓ Code Review ↓ CI ↓ Merge ↓ Release ↓ 用户 GitHub 恰好把这条链路中的多个环节连接起来。 其中： Issue 负责描述和跟踪工作； Pull Request 负责提交代码变更； Code Review 负责验证代码； Actions 负责自动化检查； Ruleset 负责约束仓库规则； Release 负责向用户交付稳定版本。 GitHub 官方也将 Pull Request 模板、Code Owners、受保护分支和 Rulesets 作为标准化 Pull Request 和保护重要分支的重要工具。(GitHub：管理和标准化 Pull Request) 因此，GitHub 工程化的核心并不是「会使用多少 GitHub 功能」，而是建立一条可追踪、可审查、可自动化、可发布的软件交付流程。 Issue：把需求和问题变成可追踪任务 Issue 是项目管理的起点。...

GitHub Actions 是什么 GitHub Actions 是 GitHub 提供的 CI/CD 自动化平台，可以根据代码仓库中的事件自动执行构建、测试、发布和部署任务。 例如，一个 PHP 项目可以设计成： 开发者 │ │ git push ▼ GitHub Repository │ │ push event ▼ GitHub Actions │ ├── Checkout ├── Install Dependencies ├── Run Tests ├── Docker Build ├── Docker Push └── Deploy │ ▼ Production GitHub 官方将 Actions 的核心组成划分为 Workflow、Job、Step、Runner 和 Action。一个 Workflow 可以包含一个或多个 Job，每个 Job 又由多个 Step 组成。Job 默认可以并行执行，也可以通过依赖关系串联起来。(GitHub Actions 官方文档) GitHub Actions 官方文档 GitHub Actions 最大的价值并不是「帮你执行几个 Shell 命令」，而是把代码仓库、自动化测试、镜像构建、镜像仓库和部署环境连接起来。...