企业官网建设流程全解析

项目标题是"GitLib 功能介绍与在 Scrum 敏捷模式中的应用"。这类题目很容易写成产品说明书加敏捷宣言的拼盘，但我这几年带着不同规模的团队把代码托管平台从"能拉能推的仓库"改造成"敏捷流程的实际载体"，踩过的坑比看过的文档多。下面这份内容就是我的完整实践记录，从功能拆解到 Sprint 落地，从配置代码到排查手册，尽量把每个"为什么这么设计"讲透。

Scrum 讲的是短周期、可交付增量、透明与自检，但很多团队的实际状态是：站会上靠嘴同步进度，看板上的卡片没人更新，Sprint 结束前一天集中合并代码然后集体救火。问题不在敏捷方法本身，而在于流程信息和代码信息分居两套系统。GitLib 这类自建代码托管平台恰好是能把两者缝起来的那个点——它既有仓库、分支、合并请求这些代码侧能力，又有 Issue、看板、里程碑、流水线门禁这些流程侧能力。工具本身中立，关键在于你怎么用。

1. 整体设计与思路拆解

1.1 GitLib 到底是个什么东西：从"能存代码"到"能承载流程"

先把概念说清楚，避免后面所有讨论都建在模糊认知上。GitLib 在这里指的是一套自建的、围绕 Git 版本控制协议构建的代码协作平台。它的底座是标准的 Git 仓库——克隆、提交、分支、合并、标签，这套东西和你在本地敲命令没有任何区别；但平台在仓库之上加了一整层协作设施：命名空间与分组管理、合并请求、行级代码评审、Issue 跟踪、看板、里程碑、权限角色、流水线编排、Webhook 事件分发、制品与环境部署记录。

这层设施是理解 GitLib 价值的关键。单纯一个 Git 仓库只能回答"代码现在长什么样"，而 GitLib 要回答的是另外几个问题：这次改动是谁提的、为了解决哪张需求卡片、谁审过、自动化检查过没过、能不能合并、合并之后有没有成功部署到评审环境、这个 Sprint 的增量到底交付了什么。从一个存储工具升级为一个可追溯的协作过程记录器，这才是它在敏捷团队里的真实定位。

我一般跟新同事这么打比方：Git 仓库是仓库本身，负责保管货物；GitLib 是仓库加门卫、加台账、加质检线、加发货单。货物没变，但你能知道每件货什么时候进的、谁验的、发往哪里、有没有被退回。对小团队来说这层东西可能显得重，但只要团队超过五六个人、同时并行两条以上需求线，没有台账你迟早会在"这段代码为什么这么改"上耗掉大量时间。

1.2 Scrum 的痛点在工具层面的映射

把 Scrum 的几个核心活动摊开看，会发现它们的痛点几乎都能在 GitLib 的功能表里找到对应项，这也是我主张把两者打通的根本原因。

Sprint 规划痛在需求颗粒度太粗。"用户登录优化"这种卡片丢给开发，做三天也说不清完成没有。如果每张卡片在 GitLib 的 Issue 里就被拆成带验收条件的子任务，并且规定"一个子任务对应一个合并请求、一个合并请求的变更规模不超过一定行数"，规划阶段的模糊性会被强制压缩。

每日站会痛在信息滞后。口头汇报"昨天在写接口"，实际上代码还停在本地没推。如果规定每天站会前必须把当天的工作分支推上去、把 Issue 状态改为进行中、把卡住的点用标签标出来，站会就变成核对着看板做异常处理，而不是轮流念日记。

评审与完成定义（DoD）痛在标准漂移。每个人心里的"完成"不一样。GitLib 的合并请求模板加流水线门禁可以把这个标准固化成机器可校验的条件：必须有至少一位评审人批准、流水线全绿、没有未解决的讨论、覆盖率不低于阈值、关联了 Issue 编号。达不到就是不能合，不依赖自觉。

Sprint 回顾痛在没有数据。回顾会变成情绪交流会，谁都记得"上次发布很痛苦"，但说不出本周期的合并请求平均评审时长是多少小时、变更失败率多少。GitLib 的事件流天然记录这些，导出一下就能得到客观口径。

1.3 方案选型：为什么用平台内建能力而不是外挂一堆工具

常见的替代方案是"代码托管 + 独立看板工具 + 独立 CI 服务 + 独立文档系统"，四个系统靠人工或第三方集成串起来。我做过这种组合，也用 GitLib 内建能力做过单栈方案，对比下来差异很明确。

选单栈的核心理由不是"省事"，而是状态一致性。敏捷最怕的就是看板显示"已完成"、代码其实没合、流水线是红的。多系统拼装时这种不一致是常态，因为同步总有延迟和遗漏；同一平台内，合并动作、Issue 关闭、流水线状态是同一次操作的结果，人为制造不一致的空间被压缩了。

自建的代价也要说清楚：你需要有人负责升级、备份、容量规划和账号治理。我的经验是，团队规模在十人以下时，自建运维的成本会吃掉一部分收益，可以先从托管方案起步；十五人以上、有代码合规要求或需要深度定制的团队，自建才划算。这个判断线不是绝对的，取决于你们有没有一个愿意兼着做平台维护的人。

2. GitLib 核心功能盘点与关键参数

2.1 仓库结构、分支模型与保护规则

仓库组织上我强烈建议按"产品线 → 子系统 → 仓库"三级命名空间划分，而不是所有人平铺在一个大组里。命名空间本身是权限边界，你在上层给整个产品线授权，下层仓库自动继承，新增仓库不用重复配置。这一点在团队扩编时体现得最明显——我做过的项目里，命名空间规划混乱的那次，半年后光梳理权限就花了两周。

分支模型是敏捷落地成败的分水岭。我推荐主干开发 + 短生命周期特性分支：

• main：受保护，永远可发布，合并必须走合并请求
• feat/<issue-id>-<短描述>：功能分支，生命周期控制在三天以内
• fix/<issue-id>-<短描述>：缺陷修复分支
• hotfix/<日期>-<短描述>：紧急修复，允许单人批准但要事后补评审
• release/<版本号>：仅在有对外版本节奏时使用，否则用标签代替

为什么不用长期存在的 develop 分支？因为长期分支的合并冲突成本随时间线性增长，而且它天然鼓励"攒一批再合"，与 Scrum 每周期交付可运行增量的要求直接冲突。主干开发把集成动作拆散到每一天，冲突小而频繁，代价是要求团队的自动化测试足够扎实——这是必要投入，不是可选项。

保护分支的配置项需要说清楚每个参数背后的考虑：

2.2 合并请求与代码评审机制

合并请求是 GitLib 里承载"增量"这个概念的最小单元。设计上我坚持一条原则：一个合并请求 = 一个可独立评审、可独立回滚的逻辑变更。它对应一张 Issue 或一个子任务，不对应"我今天干的活"。

评审质量与变更规模强相关。行业里比较通行的经验值是单次变更控制在 400 行以内，超过 800 行评审有效性会急剧下降——不是评审人不认真，而是人脑一次能保持上下文的量有限。我在一个项目上做过统计：变更在 200 行以内的合并请求，平均能收到 2.3 条实质性评论；超过 1000 行的，平均只有 0.4 条，而且多数是格式和命名。这个数据后来成了我们拆分任务的硬依据。

评审人分配上，用代码所有者机制比手工点名可靠。在仓库里放一个所有者声明文件，指定哪些目录由谁负责，合并请求自动带出评审人。好处是责任清晰、不依赖记忆；坏处是核心模块的负责人容易成为瓶颈，所以我会再配一套轮值制度，把次要模块的评审分给其他成员，避免所有合并请求都堵在一两个人身上。

行级评论有个容易忽略的用法：把评审意见分成"必须修改"和"建议讨论"两类，用不同的标签或前缀区分。前者不解决不许合并，后者记录在案但不阻塞。我见过太多团队因为一个命名风格的讨论卡住三天的合并请求，这不是严谨，是流程设计失误。

2.3 Issue、看板与 Sprint 里程碑

Issue 系统是 Scrum 需求侧的唯一真实来源。我的配置习惯是：

• Issue 模板：至少三套——需求、缺陷、技术债。需求模板强制填写用户故事句式、验收条件、涉及模块；缺陷模板强制填写复现步骤、影响版本、严重级别。模板看起来是小功能，实际能省掉大量来回澄清。
• 标签体系：用三层标签，类型（feature/bug/debt）、优先级（P0-P3）、状态补充（blocked/need-info）。标签别超过十五个，超过就没人用了。
• 里程碑：一个里程碑对应一个 Sprint，命名带日期范围，规划会结束时锁定范围，中途新增需求开新里程碑而不是往里塞。
• 看板列：待办、进行中、待评审、验证中、已完成。我不建议做太多列，"待评审"和"验证中"分开是因为这两个环节的瓶颈完全不同——前者卡人，后者卡环境。
• 权重或故事点：选一种，别混用。有了量化口径，燃尽才有意义。

看板与合并请求的联动是最有价值的细节：Issue 关联合并请求后，合并请求一合并，Issue 可以自动流转到"验证中"，合并请求被流水线标红则自动打上阻塞标记。这样看板上的状态就不是人手动拖出来的，而是代码事实的投影。手动拖拽的看板最多维持两周的准确性，之后就会退化成装饰品。

2.4 流水线与 Webhook 的事件驱动

流水线在 Scrum 里的作用不只是"跑测试"，它是完成定义的执行者。我的标准阶段划分是五段：

1. 构建：编译或打包，产出制品，缓存依赖
2. 测试：单元测试 + 集成测试，输出覆盖率报告
3. 扫描：静态检查、依赖漏洞、密钥泄露检测
4. 打包：生成可部署制品，打上提交短哈希作为版本标识
5. 部署评审环境：只对非主干分支执行，供产品侧验收

关键参数有三个容易配错：制品保留期（太长占空间，太短回溯困难，我一般设三到七天）、缓存策略（按依赖锁文件哈希做键，锁文件不变就复用，这一步能把构建时间砍掉一半以上）、并发与超时（作业超时要设，我见过一个卡死的任务把整条流水线堵了两天的案例，最后是靠手动取消才恢复）。

Webhook 负责把事件推给外部系统，比如把发布结果同步到内部通讯群、把流水线失败推给值班人。要提醒的是幂等性：Webhook 会因为超时重投，接收端必须能按事件 ID 去重，否则你会收到三条一模一样的告警，然后开始怀疑人生。

2.5 权限与可见性模型

角色权限是自建平台最容易埋雷的地方。常见的五级角色大致是：访客（只读）、报告者（可提 Issue）、开发者（可推非保护分支、可提合并请求）、维护者（可合并、可改配置）、所有者（可删仓库、可改权限）。

我的经验是默认最小权限，按需提升，定期回收。三条硬规矩：

• 主干分支对所有人（包括维护者）禁止直推，只走合并请求；
• 生产环境的部署凭据不放在仓库变量里，用独立的受保护凭据，且仅对保护分支开放；
• 每季度做一次权限复审，重点清理离职人员和跨项目临时授权。

第三条听起来官僚，但我确实遇到过离职两个月的账号还挂着维护者权限的情况，是因为当时为了赶进度临时给的，之后没人记得收回。

3. 在 Scrum 各环节落地

3.1 Sprint 规划：把需求拆到"可提交"的颗粒度

规划会的产出不该是一堆卡片标题，而应该是一组可以直接开工的原子任务。我在会上的做法是带着团队当场拆 Issue：每张需求 Issue 下面挂子任务，每个子任务满足三个条件——能在一个合并请求里完成、有明确验收条件、预计工时不超过一天半。

超过一天半的子任务要继续拆，因为它意味着你对这件事的理解还不够细，或者它本身就是多件事。这条规则在实践中的效果非常直接：拆不动的任务，通常是在等外部依赖或者需求本身没想清楚，早点暴露比做到一半发现好得多。

规划会结束时的检查项：每个子任务都有负责人、都有预估、都已经关联到本 Sprint 的里程碑、都标注了涉及模块。涉及模块这个字段很关键，它决定了后面自动分配评审人和评估回归范围。我见过团队因为漏标模块，导致一次数据库迁移脚本被当成普通业务代码评审，上线时才发现没人审过 SQL。

3.2 开发期：分支命名与提交信息的约定

约定这件事，写了文档没人看的概率接近百分之百，所以必须机器校验。我们的规则很朴素：

• 分支名：<type>/<issue-id>-<kebab-case-描述>，例如feat/SPR-142-login-retry
• 提交信息：<type>(<scope>): <subject> [<issue-id>]，例如fix(auth): 修复令牌过期后未刷新 [SPR-142]
• 正文说明"为什么改"而不是"改了什么"，改了什么看差异就行

校验放在两个位置：本地提交钩子做第一道拦截，服务端钩子做第二道兜底。本地钩子可以被绕过，服务端不能，所以必须有服务端那道。

一条实际心得：不要在提交信息里写"修改若干问题""优化代码"这类词。半年后回溯时，这类提交会变成完全无法解读的黑洞。我现在的习惯是把决策背景写进提交正文，比如"选择重试三次而非队列，是因为接口幂等性由上游保证，队列会引入额外部署依赖"——这种信息在代码里看不出来，但它是未来维护者最需要的东西。

3.3 每日站会：让看板和流水线替你说话

站会的组织形式我改过好几版，最后固定成"先看板、后异常"的十五分钟结构。开会前每人有五分钟自检时间：昨天的分支推了没有、Issue 状态更新了没有、流水线是不是红的、有没有卡在等评审的合并请求。

站会开始后跳过"我昨天做了什么"，直接从看板的阻塞列开始过。谁有卡片超过两天没动、谁的合并请求超过二十四小时没人评审、哪条流水线连续失败，这些才是需要处理的信息。剩下的正常推进项一句话带过。

这个改动的效果比想象中大。原来站会四十分钟，一半时间在同步彼此已经知道的信息；改成异常驱动后压到十五分钟，而且真正的问题会被揪出来。副产品是看板准确性上去了——因为大家都知道自己不更新状态，第二天站会上会被点名。

3.4 评审与完成定义：把标准交给机器执行

完成定义最怕写成一段漂亮的话贴在墙上没人看。我的做法是把它翻译成合并请求的准入条件：

• 至少一位评审人批准，核心模块需要代码所有者批准
• 流水线全部通过，覆盖率不低于约定阈值，不允许通过降低阈值来过关
• 所有讨论已解决，或已明确标记为不阻塞
• 关联了 Issue 编号，Issue 的验收条件逐条勾选
• 变更规模在约定范围内，超出需要在描述里说明原因
• 有数据库变更、配置变更、依赖升级的，必须在描述里单列一节说明影响和回滚方式

这套条件里最难坚持的是最后一条。它需要写的人在提交前真的想过"这东西上线出问题怎么退"，但恰恰是这一条救过我。有一次一个依赖小版本升级带进了不兼容的行为变更，因为描述里写了回滚方式，从发现到恢复只用了十一分钟，而不是花两小时重新构建旧版本。

3.5 Sprint 回顾：用数据代替印象

回顾会要有数据支撑，否则讨论会漂移。GitLib 里能直接拿到的度量项，我常用这几组：

这些数据不是用来考核人的，一旦被拿去排名，数据立刻失真。我一般只做趋势对比，拿本 Sprint 和上三个 Sprint 的均值比，看哪条线在恶化，然后在回顾会上针对那一条讨论改进项。经验是每次回顾只挑一到两个改进项，多了执行不了，下个 Sprint 一看还是老样子，团队会失去对回顾会的信任。

4. 实操过程与关键环节实现

4.1 仓库初始化与分支保护配置

新项目起步时，我按这个顺序做，顺序不对后面会返工：

# 1. 在平台创建命名空间与仓库（建议用界面操作，便于配继承权限） # 2. 本地初始化，设置主干 git init git checkout -b main git add . git commit -m "chore(init): 初始化项目骨架 [SPR-1]" git remote add origin <仓库地址> git push -u origin main # 3. 立刻打上保护，别等有代码了再补 # 保护分支配置项：禁止直推、最少 1 位批准、流水线必须通过、讨论需解决 git tag -a v0.1.0 -m "初始骨架" git push origin v0.1.0

保护分支一定要在第一次合并之前配好。我吃过亏：项目跑了两周才想起配保护，结果历史里已经有一堆直推，回头做审计时分不清哪些改动走过评审。

接着配三份模板文件，放在仓库的模板目录下，平台会自动套用到新建的 Issue 和合并请求上。合并请求模板大致长这样：

## 变更说明 <!-- 一句话说清这个 MR 解决什么问题 --> ## 关联 Issue Closes # ## 变更类型 - [ ] 新功能 - [ ] 缺陷修复 - [ ] 重构 - [ ] 依赖升级 ## 验收条件自检 - [ ] 验收条件 1 - [ ] 验收条件 2 ## 影响与回滚 - 影响范围： - 是否需要数据变更： - 回滚方式： ## 自测记录 <!-- 怎么验证的，截图或日志链接 -->

这份模板的作用不是形式主义，而是强迫提交者在合并前把"影响与回滚"想一遍。模板字段越少越好用，我现在控制在六项以内，超过十项的模板最后所有人都只填第一行。

4.2 流水线配置与参数取值

流水线配置我一般写成四个阶段，附上关键参数的取值逻辑：

stages: - build - test - scan - package variables: APP_ENV: "ci" CACHE_KEY: "deps-${CI_COMMIT_REF_SLUG}" build: stage: build cache: key: ${CACHE_KEY} paths: - .deps/ script: - ./scripts/fetch-deps.sh - ./scripts/build.sh artifacts: paths: - dist/ expire_in: 3 days test: stage: test script: - ./scripts/test.sh --coverage-out coverage.xml - ./scripts/check-coverage.sh coverage.xml 75 coverage: '/总覆盖率:\s+([0-9.]+)%/' artifacts: when: always reports: junit: reports/junit.xml expire_in: 7 days scan: stage: scan script: - ./scripts/lint.sh - ./scripts/dep-audit.sh --fail-on high allow_failure: false package: stage: package only: - main script: - ./scripts/package.sh "build-${CI_COMMIT_SHORT_SHA}" artifacts: paths: - out/ expire_in: 14 days

几个参数的选择理由：

覆盖率阈值取 75%是权衡结果。门槛设 90% 在存量项目上等于永远红，团队会直接关掉门禁；设 60% 又拦不住明显缺测试的模块。我的做法是新模块按 80% 卡，存量模块按"不低于上期覆盖率"卡，用增量口径而不是绝对值口径，这样既能提升又不会让人绝望。

扫描设allow_failure: false是有意的。安全扫描一旦允许失败，就等于没有。代价是误报会挡住合并，所以配套要有一个明确的误报豁免流程：在代码里写带工单号的豁免注释，评审时可见，不能靠改配置全局关掉。

制品保留期分级：构建产物三天，测试报告七天，可部署制品十四天。分级的原因是存储成本随保留时间线性增长，全部设十四天会让平台存储很快见底。

缓存键用分支标识而不是固定字符串，是为了避免不同分支互相污染缓存。代价是分支首次构建慢，可以在主干构建成功后让特性分支继承主干缓存，这个优化能省掉大量等待。

4.3 提交信息与分支名的自动校验

服务端钩子的核心逻辑用一个脚本实现，思路是把规则写死，不给人留绕过空间：

#!/usr/bin/env bash # 校验分支名与提交信息格式，失败则拒绝推送 set -uo pipefail BRANCH_PATTERN='^(feat|fix|hotfix|chore|release)/[A-Z]+-[0-9]+-[a-z0-9-]+$' COMMIT_PATTERN='^(feat|fix|refactor|chore|test|docs)(\([a-z0-9_-]+\))?: .+ \[[A-Z]+-[0-9]+\]$' refname="$1" if [[ "$refname" == refs/heads/* ]]; then branch="${refname#refs/heads/}" if [[ "$branch" != "main" && ! "$branch" =~ $BRANCH_PATTERN ]]; then echo "分支名不合规: $branch" echo "示例: feat/SPR-142-login-retry" exit 1 fi fi while read -r _ _ _ _ msg; do [[ -z "${msg:-}" ]] && continue if [[ ! "$msg" =~ $COMMIT_PATTERN ]]; then echo "提交信息不合规: $msg" echo "示例: fix(auth): 修复令牌过期后未刷新 [SPR-142]" exit 1 fi done

规则严格到这种程度，前两周一定有人抱怨。我的处理方式是给一次"过渡期"：第一周只告警不拦截，第二周开始拦截，同时在团队群里每天贴一次最常见的错误写法。过了三周就没人提了，因为大家都形成了肌肉记忆。

有一个例外必须留：main分支本身不套分支命名规则；回滚用的revert-前缀分支单独放行。规则要有例外口子，但例外必须是显式列举的，不能是模糊的"特殊情况自行判断"。

4.4 发布与回滚流程

发布流程我坚持"标签即版本"：每次上线从主干打一个附注标签，标签消息里写清版本号、包含的主要变更、数据库变更标记。回滚不靠重新构建旧代码，而是靠重新部署上一个标签对应的制品。

# 发布 git checkout main && git pull git tag -a v1.4.0 -m "v1.4.0: 登录重试机制、订单导出优化; 含数据库变更 20240612_add_retry_col" git push origin v1.4.0 # 流水线监听到标签事件，自动构建并部署至评审环境，人工确认后部署生产 # 回滚（优先用前一版本制品，不重新构建） # 在平台环境页面选择 v1.3.2 的制品执行重新部署 # 若必须回退代码，用反向合并而非重置 git checkout -b revert/v1.4.0 main git revert --no-commit v1.3.2..v1.4.0 git commit -m "revert: 回退 v1.4.0 全部变更 [SPR-160]"

为什么坚持用反向合并而不是重置主干？因为重置会抹掉历史，导致"这段代码为什么消失"永远查不到。反向合并留下完整记录，代价是多几个提交，完全值得。

发布窗口我一般定在周一到周三，避开周五。这不是迷信，是因为周五发布出问题要占用休息时间处理，而且回滚决策在疲劳状态下容易出错。这条规矩在团队里争议最小，执行得最好。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

下面这些是我在不同项目里反复遇到的，按出现频率排序：

5.2 分支混乱的治理经验

分支混乱是所有团队都会经历的一个阶段，表现为远端堆积几十个半年没动的分支，谁也不敢删，因为不知道哪个还有用。

治理办法分三步。第一步做一次全面盘点，用脚本拉取所有远端分支的最后提交时间和合并状态，把已合并的直接批量删除，把未合并但超过三个月的列出来人工确认。这一步通常能清掉七成。第二步设自动清理规则：合并请求合并后自动删除源分支，这个开关一定要打开，它是治本的措施。第三步改习惯，分支名带 Issue 编号，Issue 关闭时分支自然失去存在理由。

有个细节要注意：自动删除源分支会让某些人本地还留着旧分支，下次推送时又把它推回远端。所以合并后要在群里提醒一句"记得清理本地分支"，或者干脆在合并请求模板里加一条检查项。

5.3 流水线故障的排查顺序

流水线出问题时，排查顺序很重要，顺序错了会在错误方向上耗很久。我的固定顺序是：

先看是环境问题还是代码问题。判断依据是同一提交重跑一次，如果这次过了，大概率是环境抖动（依赖源不稳定、容器资源不足、并发冲突）；如果稳定失败，才是代码或配置问题。这一步能省掉大量无谓的代码排查。

再看失败发生在哪个阶段。构建阶段失败一般是依赖或编译配置；测试阶段失败要看是断言失败还是超时，超时的常见原因是测试里有真实网络调用或休眠等待；扫描阶段失败要区分真问题和误报，误报走豁免流程；打包阶段失败多数是路径或权限问题。

最后看是不是最近改的。用二分法在提交历史里定位，这也是为什么我坚持主干历史保持线性——非线性历史做二分定位会异常痛苦。

我踩过的一个典型坑：某次流水线在测试阶段随机失败，重跑就过，团队当成偶发忽略了两个月。后来定位到是一个测试用例依赖了当前时间戳的秒级精度，跨秒执行时偶尔失败。这类"偶发"问题几乎都有确定性的根因，忽略它的代价是团队逐渐对红色流水线麻木，那才是真正的危险。

6. 我个人的几条实践体会

关于工具改造的节奏，我的体会是一次只改一件事，改完观察两个 Sprint。有次我心急，同一个 Sprint 里上了分支保护、覆盖率门禁、提交信息校验三件事，结果团队一周内被拦了四十多次，情绪反弹很大，最后不得不回退其中两项。后来改成一次一项，每项上线前先告警一周，接受度完全不同。

关于规则的执行，我的体会是规则要少，但少数的规则必须绝对执行。十条规则执行八条，不如三条规则执行三条。因为一旦有规则可以被绕过，所有规则都会失去约束力，团队会学会"哪条是真要遵守的"。

关于度量的使用，我的体会是只用来改流程，不用来评人。这个边界一旦模糊，数据就开始失真，最后你会得到一堆好看的假数字和一堆真实的隐藏问题。

最后一个具体建议：如果你正准备把 GitLib 引入团队的 Scrum 流程，别一上来就配置全套。先做两件事——把 Issue 和合并请求关联起来，把主干分支保护配上。这两件事投入最小、收益最直接，跑一个月看看站会和回顾会的变化，再决定要不要继续往下加。工具是手段，流程能不能真的跑起来，取决于团队愿不愿意每天花五分钟把状态更新准确，这件事没有工具能替你完成。