Git + GitHub 实战：PR、Issue、CI/CD 完整指南

Git 是版本控制工具，GitHub 是建立在 Git 之上的协作平台。学会 Git 只是第一步，真正跟别人协作开发，还要学会 GitHub 的 PR、Issue 和 CI/CD。这篇文章从实战出发，带你把这套工具链真正用起来。

Pull Request：代码审查的核心

你在自己的分支上做完了一个功能，怎么把代码合并到 main 分支？答案是提 Pull Request。

PR 的本质是一个"合并请求"。你把分支推上去，告诉仓库管理员：我改了这些内容，请 review 一下，没问题的话合并到 main。

PR 的完整流程

一个典型的 PR 流程是这样的：从 main 创建功能分支（git checkout -b feature/search），开发完成并推送分支（git push origin feature/search），在 GitHub 上提 PR，同事在页面上 review 代码并提出修改意见，你修改后再推送到同一分支（PR 会自动更新），review 通过后通过 Squash Merge 或普通 Merge 合并到 main。

在创建 PR 的时候，GitHub 支持模板功能。团队的仓库通常会配置 PR 模板，要求填写改动说明、测试方法和关联的 Issue 编号。这不只是流程要求，更是为将来排查问题留下记录。别人（也包括几个月后的你自己）一眼就能搞清楚这个 PR 为什么提交。

PR 页面能做什么

PR 页面会显示你改了哪些文件、每个文件的具体改动（以红色和绿色标注删除和新增的行）。同事可以在具体的某一行上留评论，指出问题、提出建议，你也可以回复、讨论。这个行内评论功能是代码审查最核心的协作机制。

如果 PR 还不太完善但希望同事先看看进度，GitHub 支持创建 Draft PR（草稿 PR）。Draft 状态的 PR 不会被意外合并，CI 也可能不会运行全套测试。等一切准备就绪后，再点"Ready for Review"正式请求审查。

合并策略有三种

GitHub 提供三种 PR 合并方式：Merge Commit（普通合并，保留完整的历史记录，会产生一个合并提交）、Squash Merge（压缩合并，把一个 PR 的所有提交合并成一个，历史更干净）、Rebase Merge（变基合并，线性历史，不产生合并提交）。团队通常会在仓库配置里统一设置推荐的合并策略。对于个人项目，推荐用 Squash Merge，能避免 feature 分支上的那些"修 typo"、"再改一下"、"wip"等琐碎的提交记录污染 main 页的历史。

Issue：任务追踪

Issue 是 GitHub 的任务管理系统。一个 Issue 可以是一个 bug 报告、一个功能需求、一个讨论话题，也可以是一篇待发布的文章大纲。

怎么写好一个 Issue

创建 Issue 时写清楚标题和描述。如果是 bug 报告，要写：复现步骤、期望行为、实际行为、截图或日志、系统环境（操作系统、浏览器版本等）。如果是功能需求，要写清楚：需求背景和目的、具体功能描述、验收条件、参考竞品或类似功能（如果有）。

GitHub 支持 Markdown 语法写 Issue 描述，也支持插入图片、清单、代码块。善用 Markdown 的表格和有序列表可以让长篇描述层次分明。

Issue 的标签和看板

Issue 可以打标签分类：bug、feature、help wanted、documentation、good first issue 等。团队通常会自定义标签体系，比如 priority:p1、priority:p2 标注优先级，status:in-progress 标注进度。

可以把 Issue 关联到项目看板（Projects），以看板视图管理迭代。GitHub 的 Projects 模块支持 Kanban 板和表格视图，拖拽 Issue 卡片就能变更状态。配合 Milestone（里程碑）功能，可以把多个 Issue 归类到一个版本发布计划中。

一个常见的工作流

用户或测试提 bug → 创建 Issue 填写复现步骤 → 开发者领取 Issue 并分配给自己 → 创建分支修复 → 提 PR 时写"fixes #123" → PR 合并后 Issue 自动关闭。这个"fixes #123"是关键写法，当一个包含此描述的 PR 被合并后，编号 123 的 Issue 会自动在 GitHub 标记为关闭，不用手动再去关。你也可以用"closes #123"或"fixes #123"等写法，GitHub 会自动识别。

GitHub Actions：自动化 CI/CD

每次提交代码都手动跑测试、打包、部署太累了。GitHub Actions 可以自动完成这些工作，并且深度集成到 GitHub 平台中。

你的第一个 Workflow

在仓库根目录创建 .github/workflows/ 目录，放一个 YAML 文件：

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

这段配置的意思是：每次 push 或提 PR 时，自动在 Ubuntu 系统上安装 Node.js 20，然后安装依赖（npm ci 比 npm install 更严格，会严格按照 lock 文件安装）、跑测试。Actions 市场上有大量的预置 Action，比如部署到 AWS、发布 GitHub Release、发送 Slack 通知等，拿来就能用。

用矩阵策略测试多版本

实际项目往往需要保证多个版本的兼容性。Actions 的 matrix 功能可以让你在多个配置下并行跑同一个 job：

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: ['18', '20', '22']

这样一次 push 会触发三个并行任务，分别测试 Node 18、20、22。任何一个失败都会让 PR 显示失败状态。

部署 Workflow

CI 通过之后，下一步是 CD（持续部署）。很多团队会在 PR 合并到 main 后自动触发部署：

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm run build
      - name: Deploy to production
        run: ./deploy.sh

对于前端项目，也可以直接把构建产物推送到 gh-pages 分支实现 GitHub Pages 部署，或者通过 FTP/SFTP 上传到自有服务器，或者打包成 Docker 镜像推送到镜像仓库。GitHub Actions 生态里几乎覆盖了你所有能想到的部署场景。

保护分支配置

自动化的 CI 跑起来了，但还需要保证 main 分支不会被随意污染。在 GitHub 仓库的 Settings → Branches 里，可以给 main 分支加保护规则（Branch Protection Rules）。

常用的保护规则包括：

• Require pull request reviews before merging：合并前必须有人 review 通过，可指定至少 1 人或 2 人通过。
• Require status checks to pass before merging：CI 测试必须通过，还可以指定具体的检查项（比如 lint、test、build 都要通过）。
• Require branches to be up to date before merging：合并前分支必须是最新的，防止基于旧分支开发导致合并后发现冲突。
• Require signed commits：要求提交的 GPG 签名验证，保证提交者身份可信。
• Include administrators：管理员也要遵守规则，不能绕过（这一点强烈建议开启，否则保护规则形同虚设）。

开启这些规则后，没有人能直接把代码推送到 main 分支。每个人都必须走 PR 流程，必须有人 review，必须通过 CI。这是 Github-flow 工作流的最低安全保障。

.gitignore 和许可证

这两个文件是项目标配，但很多人会忽略。

.gitignore 告诉 Git 哪些文件不要跟踪，常见的有：node_modules/（依赖包，太大）、.env（密钥文件，绝对不能进仓库）、dist/ 或 build/（编译产物）、*.log（日志文件）、.DS_Store（macOS 系统文件）、Thumbs.db（Windows 缩略图缓存）。GitHub 提供了各项目的标准 .gitignore 模板，在新建仓库时可以直接选。

LICENSE 文件声明你的代码用什么许可证。MIT 是最宽松的，几乎不限制用途。GPL 要求衍生作品也开源，适合希望保证开源延续的项目。Apache 2.0 加入了专利授权条款，企业场景用得多。如果仓库没有 LICENSE，默认保留所有权利，别人不能合法使用和使用。别小看这一点，很多开源纠纷就是从缺少许可证开始的。

README.md

README 是项目的门面。别人打开你的仓库第一眼看到的就是它。

好的 README 应该包含：项目一句话介绍、功能特性列表（用图标或截图展示效果）、安装步骤、使用示例（带代码片段）、API 文档或链接、本地开发指南（怎么 clone、怎么装依赖、怎么跑起来）、贡献指南（CONTRIBUTING.md 或写在这里）、许可证信息。

如果你不想写长 README，至少要有项目介绍和安装步骤。没有 README 的项目，别人看不懂也不敢用。一个小技巧：你可以在 README 里添加 badges（徽章），比如 CI 状态、代码覆盖率、版本号、许可证等。这些小小的彩色徽章能让项目看起来更专业。

补充几个实用功能

CODEOWNERS

在仓库根目录创建 .github/CODEOWNERS 文件，可以指定某些目录或文件的负责人：

# 前端代码由前端团队审查
/src/** @frontend-team
# 数据库迁移脚本必须经 DBA 审查
/migrations/** @dba-team

当 PR 修改了这些目录的文件时，会自动 assign 对应的负责人来 review，避免 PR 找不到合适的人来看。

GitHub Discussions

如果你的仓库需要讨论功能而非追踪具体任务，用 Discussions 比 Issue 更合适。Discussions 支持投票、最佳答案标记，更像论坛，适合开放式讨论、问答、公告。Issue 适合可追踪、可关闭的具体任务。两者配合使用效果最好。

Release 管理

在 GitHub 上可以为仓库发布 Release，关联 git tag。Release 里可以写更改日志（支持自动根据 PR 生成）、上传构建产物。Release 还可以通过 GitHub Actions 自动触发——比如往代码里推送一个 v1.0.0 的 tag，就自动创建一个 Release 并打包上传。

最后

Git + GitHub 的组合是现代开发的基础设施。Git 管代码版本，GitHub 管协作流程，Actions 管自动化。三者串起来就是一套完整的开发工作流。

建议你现在就去 GitHub 上建个测试仓库，亲手体验一遍 PR 流程、配置 Actions、设置保护分支。实际操作一遍比看十遍教程管用。遇到搞不定的问题，GitHub 官方文档（docs.github.com）写得非常详细，是最可靠的学习资料。