GitHub / GitLab 实战篇：从仓库协作到 Pull Request / Merge Request 流程

如果说前一篇《Git 从入门到精通》解决的是“Git 命令和底层概念”，那么这篇文章更关注一个现实问题：

真正到团队里，GitHub 和 GitLab 到底怎么用，才能把协作流程跑顺。

很多人会 Git 命令，但一到实际开发平台上就会遇到这些问题：

仓库怎么初始化更规范
分支怎么建，权限怎么控
Pull Request / Merge Request 怎么提才专业
Code Review 应该看什么
Issue、Milestone、Release、CI/CD 这些能力分别怎么配合

这篇文章按“个人开发 -> 团队协作 -> 发布上线”的顺序，讲 GitHub / GitLab 在真实项目中的使用方式。

1) GitHub 和 GitLab 各自适合什么场景

先说结论：

GitHub 更适合开源协作、公开项目、社区生态、第三方集成丰富的团队
GitLab 更适合企业内网、自托管、权限管理更细、DevOps 一体化需求更强的团队

二者的共性很强，核心能力基本一致：

仓库托管
分支协作
Pull Request / Merge Request
Issue 跟踪
标签、里程碑、版本发布
CI/CD 自动化

最大的差异往往不是“能不能做”，而是“默认体验和侧重点不同”。

简单理解：

GitHub：社区属性更强，开源协作体验很成熟
GitLab：项目管理和流水线整合更重，更像“代码平台 + DevOps 平台”

2) 第一次创建仓库，建议怎么做

无论是 GitHub 还是 GitLab，第一次建仓库时建议把这些基础项一次性想清楚。

2.1 仓库命名

建议：

仓库名清晰、简短、可搜索
尽量统一命名风格，例如全部使用小写加中划线

例如：

my-blog
order-service
frontend-admin

避免：

test
new-project-final
aaa-demo

2.2 README、License、.gitignore

初始化仓库时，建议至少有：

README.md
.gitignore
LICENSE（开源项目尤其重要）

一个好的 README 至少应该写清：

项目是干什么的
如何启动
如何构建
如何部署
联系方式或贡献方式

2.3 默认分支

默认建议统一为：

main 作为主分支

如果是多人团队，再考虑是否引入：

develop
release/*
hotfix/*

对于规模不大的团队，不要一开始就把分支模型搞得过重。

3) 克隆、Fork、导入仓库，分别什么时候用

3.1 `Clone`

适合你本来就有仓库权限，直接拉到本地开发。

1 2	`git clone git@github.com:your-org/project.git git clone git@gitlab.com:your-org/project.git`

3.2 `Fork`

GitHub 上尤其常见，适合：

参与开源项目
你没有主仓库写权限
先在自己名下改，再提 PR

典型流程是：

Fork 原仓库到自己账号下。
Clone 自己的 Fork。
新建分支开发。
Push 到自己的仓库。
向上游仓库发起 PR。

3.3 Import / Mirror

适合：

从其他平台迁移代码
从 SVN / 旧 Git 服务迁移
在 GitHub 与 GitLab 之间做镜像同步

如果团队正在做平台迁移，建议提前规划：

仓库权限迁移
Webhook / CI 配置迁移
Issue / Wiki / Release 是否同步

4) 团队协作里最常见的分支策略

GitHub / GitLab 都支持很多工作流，但大多数团队真正常用的只有几种。

4.1 GitHub Flow

最轻量，也最适合中小团队：

从 main 拉最新代码。
新建功能分支。
开发并提交。
Push 到远程。
发起 PR。
Review 通过后合并回 main。
自动部署或手工发布。

优点：

简单
分支少
上手成本低

前提：

main 始终保持可发布状态
测试和 CI 足够稳定

4.2 GitLab Flow

GitLab 更常鼓励把“环境”和“发布流程”也结合进来。

例如：

main 对应主线开发
pre-release 对应预发环境
production 对应生产环境

优点：

更贴近企业环境流转
适合多环境部署

缺点：

流程更重
小团队可能显得复杂

4.3 Git Flow

经典但偏重：

main
develop
feature/*
release/*
hotfix/*

它适合版本发布周期明确、流程相对传统的团队，但对很多互联网团队来说已经偏重了。

建议：

小团队优先 GitHub Flow
中大型企业看环境治理和发布模型再决定是否加重流程

5) Pull Request / Merge Request 到底怎么提

这部分是 GitHub / GitLab 实战里最核心的内容。

可以把它理解成：

GitHub 叫 Pull Request
GitLab 叫 Merge Request

本质上都是：请求把某个分支的改动合并到目标分支。

5.1 提交前的最小检查

在发 PR / MR 之前，建议先做这些事：

git status
git fetch origin
git rebase origin/main
git push origin feature/xxx

或者更保守一点，用 merge 同步：

1 2	`git fetch origin git merge origin/main`

目标是确保：

分支不是很落后
没有明显冲突
本地测试已跑过

5.2 一个合格的 PR / MR 应该包含什么

不要只写一句：

fix bug

更推荐至少包含这些信息：

改了什么
为什么改
影响范围
是否有破坏性变更
是否需要测试关注点
是否有关联 Issue

一个更像样的模板：

## 改动说明
- 新增首页标签过滤功能
- 优化分类页卡片展示

## 改动原因
- 提升内容可发现性

## 影响范围
- `/tags/`
- `/categories/`
- `source/css/custom.css`

## 测试说明
- 本地已执行构建
- 已验证移动端展示

## 关联 Issue
- closes #123

5.3 PR / MR 要尽量小

很重要的一条原则：

一次 PR / MR 只做一类事情

例如：

一个 PR 只做“搜索框优化”
另一个 PR 再做“标签页改版”

不要把这些混在一起：

页面重构
代码格式化
文案调整
Bug 修复
配置升级

因为这会直接降低 Review 质量。

5.4 Pull Request / Merge Request 模板最佳实践

很多团队已经知道“PR / MR 要写说明”，但真正落地时最常见的问题是：

每个人写法不一样
有的人写很多，有的人几乎不写
Reviewer 每次都要追问测试情况、影响范围、回滚方案

这时候最有效的做法，不是靠口头提醒，而是直接上模板。

模板的价值在于：

降低提交门槛，让作者知道该写什么
提升 Review 效率，让 Reviewer 快速抓重点
让历史记录更可追溯，几个月后还能看懂“为什么这么改”

1. 一个好模板应该包含什么

推荐至少包含这些字段：

改动背景
改动内容
影响范围
测试说明
风险评估
回滚方式
关联 Issue

如果是前端、页面、客户端项目，还建议加：

截图或录屏
浏览器 / 设备验证范围

如果是后端、基础设施、数据库项目，还建议加：

接口兼容性说明
配置变更说明
数据迁移说明

2. 推荐模板一：通用型 PR / MR 模板

这是最适合大多数团队直接落地的版本：

## 背景
- 为什么要做这次改动？

## 改动内容
- 本次具体改了什么？

## 影响范围
- 影响的模块：
- 影响的页面 / 接口：
- 是否涉及数据库 / 配置变更：

## 测试说明
- [ ] 本地已自测
- [ ] 已通过 CI
- [ ] 已补充或更新测试
- [ ] 已验证关键场景

## 风险与回滚
- 风险点：
- 回滚方式：

## 截图 / 录屏
- 如有 UI 变更，请附图

## 关联 Issue
- closes #

这个模板的特点是：

字段比较全
适合通用研发团队
Reviewer 能快速看到风险和验证情况

3. 推荐模板二：轻量型模板

如果团队规模小、改动节奏快，也可以先用更轻一点的版本：

## 改动说明
- 

## 测试说明
- 

## 关联 Issue
-

轻量模板的优点是阻力小，但前提是团队成员已经有基本协作习惯。

4. 推荐模板三：前端 / 页面改动模板

前端项目很适合把“视觉变更”和“兼容范围”写清楚：

## 背景
- 

## 改动内容
- 

## 影响范围
- 页面：
- 组件：
- 路由：

## 验证情况
- [ ] Chrome
- [ ] Safari
- [ ] 移动端
- [ ] 暗色模式

## 截图 / 录屏
- 改动前：
- 改动后：

## 关联 Issue
- closes #

5. 推荐模板四：后端 / 服务改动模板

后端项目更关注接口、兼容性和回滚：

## 背景
- 

## 改动内容
- 

## 接口 / 数据影响
- 是否影响已有接口：
- 是否新增配置项：
- 是否涉及数据库变更：

## 测试说明
- [ ] 单元测试
- [ ] 集成测试
- [ ] 本地联调
- [ ] 压测 / 核心链路验证

## 风险与回滚
- 风险点：
- 回滚方案：

## 关联 Issue
- closes #

6. 模板不要写得太重

模板不是越长越好。

如果你把模板设计成十几项必填，开发者通常会：

敷衍填写
复制粘贴空内容
把模板当成“流程负担”

更合理的做法是：

核心字段尽量少而关键
可选字段按项目类型增减
用勾选项降低填写成本

一句话说就是：

模板要帮助协作，而不是制造仪式感

7. GitHub 中如何落 PR 模板

GitHub 常见做法是在仓库里新增：

1	`.github/pull_request_template.md`

最简单的单模板方案就是这个文件。

如果你希望按场景提供多个模板，也可以使用：

1
2
3

.github/PULL_REQUEST_TEMPLATE/feature.md
.github/PULL_REQUEST_TEMPLATE/bugfix.md
.github/PULL_REQUEST_TEMPLATE/release.md

适合场景：

功能开发一套模板
Bug 修复一套模板
发布变更一套模板

这样能明显减少“不同类型改动却共用一个不合适模板”的问题。

8. GitLab 中如何落 MR 模板

GitLab 常见做法是在仓库中使用：

1	`.gitlab/merge_request_templates/`

例如：

1
2
3

.gitlab/merge_request_templates/Feature.md
.gitlab/merge_request_templates/Bugfix.md
.gitlab/merge_request_templates/Release.md

创建 MR 时可以直接选择模板。

这对企业团队尤其有用，因为不同类型变更往往对应不同审批和测试要求。

9. 模板字段和审批规则要联动

模板如果只是一段文字，但分支保护、审批规则、CI 门槛没有配合，效果会打折。

更好的组合方式是：

模板里要求写测试说明
CI 里真正执行测试
保护分支要求 CI 通过才能合并
高风险改动要求特定 Reviewer 审核

这样模板不是“装饰品”，而是流程的一部分。

10. 常见反模式

下面这些模板设计，实际效果通常都不好：

模板只有一句“请描述你的改动”
模板非常长，但没人认真填
所有项目强行共用同一套模板
模板要求很多，但团队 Review 并不关注这些字段

判断模板是否有效，一个简单标准是：

Reviewer 是否真的会看
作者是否愿意认真填
出问题后是否能靠 PR / MR 记录快速还原背景

11. 一个适合多数团队的最终建议

如果你现在就要给团队落地模板，我建议从这版开始：

## 背景
- 

## 改动内容
- 

## 影响范围
- 

## 测试说明
- [ ] 本地已自测
- [ ] CI 已通过

## 风险与回滚
- 

## 关联 Issue
- closes #

先用最小可行版本跑起来，等团队真正开始使用后，再按实际问题做迭代，而不是一开始就设计成“完美但没人愿意填”的大模板。

6) Code Review 应该看什么

很多人以为 Review 只是看“代码能不能跑”，其实远不止如此。

一个好的 Review 通常会关注这些点：

逻辑是否正确
是否引入边界问题
命名是否清晰
结构是否过度复杂
是否影响兼容性
是否有安全风险
是否缺测试或缺文档

6.1 Review 评论怎么写更专业

尽量避免：

“这里不行”
“改一下”
“这写法不好”

更推荐：

“这里在空值场景下可能抛异常，建议补一个判空分支。”
“这段逻辑可以提取成独立函数，便于复用和测试。”
“这里如果用于公共分支，建议改为 revert 流程，避免改写历史。”

好的 Review 目标不是“挑刺”，而是帮助团队把质量和共识一起抬上去。

6.2 作者收到 Review 后怎么处理

建议流程：

逐条阅读评论。
对合理意见直接修改。
对有争议的问题给出背景和理由。
修改后回复评论并重新请求审核。

不要：

默默改完不解释
看到评论就防御性很强
把讨论情绪化

7) GitHub 和 GitLab 中的权限与保护分支

多人协作时，权限控制非常重要。

7.1 分支保护（Branch Protection）

建议至少保护这些分支：

main
develop（如果你们有）
release/*（如果你们有）

常见保护策略：

禁止直接 push
必须通过 PR / MR 合并
必须通过 CI
必须至少 1 个或 2 个 Reviewer 审核通过
必须解决所有对话

这类规则在 GitHub 里常见于 Branch Protection Rules，在 GitLab 里对应 Protected Branches 和审批规则。

7.2 最小权限原则

建议：

普通开发者不给生产分支直接写权限
敏感仓库严格控制 Maintainer / Admin 数量
机器人账号和人工账号分开

如果仓库里涉及部署密钥、生产脚本、基础设施配置，这一点尤其重要。

8) Issue、Label、Milestone 怎么配合使用

如果只把 GitHub / GitLab 当“代码仓库”，其实浪费了很大一部分价值。

8.1 Issue：承载需求、缺陷、任务

Issue 不只是“提 Bug”。

它还可以用来管理：

新功能需求
技术债
重构任务
文档任务
线上问题复盘

8.2 Label：快速分类

常见标签可以这样设计：

bug
feature
docs
refactor
performance
security
good first issue

这样在项目规模起来以后，检索和筛选会非常轻松。

8.3 Milestone：按版本或阶段组织

例如：

v1.0
Q3 roadmap
blog-ux-upgrade

Milestone 非常适合把零散 Issue 聚合成一个可交付目标。

8.4 让 PR / MR 和 Issue 关联起来

在描述里写：

1
2
3

closes #123
fixes #123
related to #123

这样合并后可以自动关闭 Issue，也方便回溯变更原因。

9) Release、Tag 和版本发布

真正要把项目对外发布时，Tag 和 Release 就很重要。

9.1 Tag 是版本锚点

1 2	`git tag -a v1.2.0 -m "release v1.2.0" git push origin v1.2.0`

9.2 Release 是“面向人”的发布说明

GitHub / GitLab 上的 Release 通常会包含：

版本号
发布说明
更新内容
兼容性说明
安装包或构建产物

建议一个好的 Release Note 至少写清：

新功能
修复内容
升级注意事项
已知问题

不要只写：

1	`update release`

10) GitHub Actions / GitLab CI：把重复动作自动化

这部分是平台价值被真正放大的地方。

你可以把 CI/CD 理解为：

代码一提交，就自动帮你检查
代码一合并，就自动帮你构建
代码一打标签，就自动帮你发布

10.1 常见自动化场景

提交后自动执行单元测试
自动做 lint / format 检查
自动构建前端产物
自动部署测试环境
打 tag 后自动发布正式版本

10.2 GitHub Actions 更像“插件生态强”

GitHub Actions 的优势在于：

Marketplace 很丰富
开源项目接入成本低
和 GitHub 生态结合自然

配置文件通常在：

1	`.github/workflows/*.yml`

10.3 GitLab CI 更像“一体化平台”

GitLab CI 通常放在：

1	`.gitlab-ci.yml`

它在企业场景中很强，因为和：

仓库
权限
环境
部署
Runner

结合得很深。

如果团队已经在用 GitLab 自托管，CI/CD 往往会比“拼装式多工具方案”更统一。

11) 开源项目协作：GitHub 上最常见的实战路径

如果你想参与开源，GitHub 基本是绕不开的平台。

典型流程如下：

找到感兴趣的项目。
先看 README、CONTRIBUTING、Issues。
Fork 到自己账号下。
Clone 自己的 Fork。
新建分支修改。
提交并 push。
发起 PR。
根据维护者意见继续修改。

一个很容易被忽略的点：

开源贡献不一定非得从写代码开始

你完全可以先从这些事情开始：

修文档
补示例
复现 Bug
改错别字
回答 Issue

这往往比一上来就改核心代码更容易进入项目。

12) 企业团队里更实用的 GitLab 实战习惯

在企业内，GitLab 经常承担的不只是“代码仓库”角色，还包括流程管理和环境协同。

比较常见的习惯有：

需求从 Issue 开始
开发从 Issue 拉分支
MR 必须关联 Issue
MR 必须过流水线
MR 必须至少 1 人审核
合并到指定分支后自动部署到测试环境

一个比较顺的流程可能是：

产品或技术负责人创建 Issue。
开发领取 Issue。
从主线切 feature/issue-123-xxx。
开发完成后发起 MR。
流水线自动跑测试和构建。
Reviewer 审核通过。
合并到目标分支。
自动部署到测试或预发环境。

这种方式的好处是：

每个变更都可追溯
开发、测试、发布链路更顺
管理者也能看到进度

13) 真实项目里常见的几个坑

13.1 PR / MR 太大

症状：

一次改几千行
Review 看不完
问题容易漏

建议：

拆小
先提基础重构，再提功能改动

13.2 直接往主分支 push

这通常意味着：

绕过 Review
绕过 CI
风险直接进入主线

除非是极少数紧急管理员操作，否则不推荐。

13.3 CI 只配了但没人看

很多团队搭了流水线，但：

失败也没人处理
Warning 一直堆着
规则形同虚设

CI 的价值不在“有”，而在“真的作为合并门槛”。

13.4 Issue、PR、Release 三者割裂

如果：

Issue 不写背景
PR 不关联 Issue
Release 不写变更说明

那半年后几乎没人能快速说清“这个版本为什么这么改”。

14) 一套适合多数团队的推荐实践

如果你不确定怎么搭流程，可以先从这套“够用但不重”的方案开始：

14.1 分支模型

main：稳定主线
feature/*：功能开发
hotfix/*：紧急修复

14.2 仓库规则

主分支禁止直接 push
合并必须走 PR / MR
至少 1 位 Reviewer
CI 必须通过

14.3 提交流程

先建 Issue。
从 Issue 开分支。
小步提交。
发 PR / MR。
Review + CI 通过后合并。
打 Tag，写 Release Note。

14.4 文档习惯

README 写清启动方式
CONTRIBUTING 写清贡献流程
PR / MR 使用统一模板
Release 写清变更摘要

这一套流程足以覆盖大多数博客、Web 项目、后端服务和内部工具项目。

15) GitHub 和 GitLab 怎么选

如果你还在犹豫，给一个更直接的建议：

15.1 选 GitHub 的典型情况

做开源项目
想借助社区生态
团队对 SaaS 平台接受度高
想快速接入 Actions、Dependabot、社区模板

15.2 选 GitLab 的典型情况

企业内网或私有部署要求强
想把代码、Issue、CI/CD、环境管理放在一个平台
权限、审批、流程控制更复杂
合规和数据控制要求更高

15.3 大多数人的实际答案

很多团队并不是“纯二选一”：

开源项目在 GitHub
内部项目在 GitLab

这是很常见、也很合理的组合。

16) 总结：平台能力决定协作上限，流程质量决定项目质量

GitHub 和 GitLab 的核心价值，从来不只是“放代码”。

它们真正解决的是这些问题：

让协作流程可视化
让变更原因可追踪
让质量门槛可执行
让发布过程可复用

对个人开发者来说，学会 Git 命令很重要。

但如果你想真正进入团队协作、开源贡献或工程化开发阶段，那么你还必须学会：

怎么提一个像样的 PR / MR
怎么做 Review
怎么用 Issue 管任务
怎么用 CI/CD 守住质量
怎么把 Tag 和 Release 变成“可追溯的版本历史”

当这些流程真正跑顺之后，GitHub / GitLab 才不只是仓库平台，而会变成团队工程能力的一部分。