GitHub 协作实践：PR 流程、分支保护与 Actions 入门

在真正用起来之前，我一直觉得 Pull Request 这东西有点形式主义：改几行代码，为什么要绕”建分支、推上去、开 PR、等审查、再合并”这么大一圈？直到有一次在协作项目里，我没走 PR 直接推了 main，把别人正在测的一版配置覆盖了，对着一堆报错排查了一下午。从那以后我理解了：PR 不是流程装饰，它把”谁能改什么、改完谁确认”这件事变成了可见的记录。

一、先分清 Git 和 GitHub

这两个东西经常被混着叫，其实分工很清楚：

  • Git 是本地命令行工具，负责版本控制本身；
  • GitHub 是基于 Git 的云端代码托管平台，在 Git 之上加了 Web 协作功能：Issue、PR、Actions、权限管理。

两者通过 git push / git pull 协作。放到企业环境里，还有个更实际的对比：

维度 GitHub GitLab
形态 公有云 SaaS 支持私有化部署（CE 免费）
私有仓库 收费（有免费额度） 自建随你建
典型场景 开源项目、个人项目 企业内网代码平台

国内企业内网普遍用自建 GitLab，代码不出网。所以运维岗位日常接触 GitLab 更多，但 GitHub 的协作模型是相通的，先把 PR 这套玩明白，换平台只是换个叫法（GitHub 叫 PR，GitLab 叫 MR）。

二、连接 GitHub 的两种方式

1
2
3
4
5
6
7
# HTTPS：用 Token 认证，适合临时使用或 22 端口被封的网络
git clone https://github.com/user/repo.git

# SSH：用密钥认证，日常长期使用推荐
ssh-keygen -t ed25519 -C "you@example.com"
cat ~/.ssh/id_ed25519.pub     # 贴到 Settings → SSH and GPG keys
ssh -T git@github.com         # 看到 Hi xxx! You've successfully authenticated 就是通了

企业内网经常封 22 端口，走 SSH 的仓库会连不上，这时要么改用 HTTPS + Token，要么让网络同事放行 ssh.github.com:443。这一点在做企业项目时值得提前确认，不然 clone 一次卡十分钟。

三、把本地仓库推上 GitHub

1
2
3
git init && git add . && git commit -m "Initial commit"
git remote add origin https://github.com/user/repo.git
git push -u origin main

顺带把 Fork 和 Clone 的区别说清楚，这是两个容易混的概念：

  • Clone：把仓库下载到本地，日常开发用这个；
  • Fork：在 GitHub 云端把别人的仓库复制一份到你账户下，和原仓库保留关联，改完可以向上游提 PR——开源贡献用这个。

工作流的差别也在这：给别人的项目提 PR 要先 Fork 再 Clone；自己团队的仓库直接 Clone。

四、PR 的标准流程

一个完整的 PR 流程大概是这样：

1
2
3
4
5
6
7
8
# ① 从 main 创建功能分支
git switch -c feature/xxx
# ② 开发、提交、推送
git add . && git commit -m "feat: 增加导出功能"
git push -u origin feature/xxx
# ③ 网页上创建 Pull Request（一个 PR 只做一件事，关联 Issue 用 Closes #42）
# ④ Code Review：评论 / 通过 / 要求修改
# ⑤ 合并：Merge Commit / Squash / Rebase 三种方式，按团队规则选

合并方式的差别值得说一下：

  • Merge Commit：保留全部提交记录和合并节点，历史完整但线条多；
  • Squash：把分支里的多个提交压成一条并进 main，main 的历史干净，适合”开发过程一团乱、结果要整洁”的场景；
  • Rebase：把分支提交逐条挪到 main 顶端，线性历史，但对提交规范要求最高。

Review 环节有三种状态：Comment（评论，不阻塞合并）、Approve（通过）、Request Changes（要求修改，阻塞合并直到改完）。

写 PR 有几个实用的经验：一个 PR 只做一件事，标题写清做什么，描述里放复现步骤或截图，CI 没过先别喊人看。曾经有个项目 PR 里塞了三个功能的改动，审查的人直接退回要求拆成三个——这不算刁难，是为了出问题时能精准回滚。

五、分支保护：main 的最后防线

协作项目里，main 分支必须设保护规则，不然”误推覆盖”是迟早的事。GitHub 的分支保护常用选项（GitLab 里对应 Protected branches）：

保护选项 作用 建议
Require a PR before merging 所有改动必须走 PR 必开
Require approvals 需要指定人数审查通过 至少 1 人
Dismiss stale reviews 有新提交时旧审查自动失效 推荐
Require status checks 必须通过 CI 检查才能合并 推荐
Do not allow bypassing 管理员也不能绕过 推荐

依赖这些规则之后，我自己的起手式就变成了：新仓库先拉保护规则，再接 CI，最后才邀请协作者。

安全相关的功能也顺手记一下：

  • Dependabot：自动检测依赖漏洞并创建修复 PR；
  • Secret Scanning：扫描仓库里泄露的密钥（Token、私钥等 200 多种模式）；
  • CodeQL：代码安全分析，偏静态扫描。

运维视角最重要的一条：密钥一旦进了仓库，删除文件是不够的——历史里还在，平台扫描照样会报。正确姿势是立即去服务端撤销并轮换密钥，然后再清理 git 历史，顺序不能反。

六、GitHub Actions 最小入门

GitHub Actions 是 GitHub 内置的 CI/CD。结构上：事件（push/PR/定时）触发 Workflow，一个 Workflow 包含多个 Job，Job 里跑多个 Step。

概念和 GitLab CI 对得上：Workflow ≈ Pipeline，Job ≈ Job，Step ≈ Script。写过一个就能看懂另一个。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# .github/workflows/ci.yml 最小示例
name: CI Pipeline
on:
  push:
    branches: [main]
jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 18
      - run: npm ci
      - run: npm test

这段配置放进去，每次推 main 就会自动拉代码、装 Node、跑测试。工作里它的价值是：把”合并前必须跑通”这件事从口头约定变成机器执行。

密钥管理走 Repository secrets / Organization secrets / Environment secrets 三级，日志里自动打码，但仍然有个原则：禁止用 echo 把 Secret 打印出来调试，打码不是绝对可靠的。

一个对比感受：GitHub Actions 是 SaaS，开箱即用但机器在别人那里；GitLab 的 Runner 是自己部署的，脏活累活（装 Docker、扩机器、排网络）都是运维的活。这也是为什么企业里 CI/CD 平台的维护归运维。

收尾的一点感受

GitHub 用熟的关键是把三件事串起来：分支保护挡住误操作，PR 流程留下审查记录，Actions 保证合并的都是过了测试的代码。这三样配齐，才算把 GitHub 从”代码网盘”用成了协作平台。