资料首页 · 持续更新
gitlab+cg51 协作与持续集成资料首页
gitlab+cg51 把代码托管、合并请求评审与持续集成流水线放在同一条工作链路上：代码从仓库分支出发，经提交与评审进入流水线，再产出可追溯的制品与记录。这里把仓库结构、分支约定、流水线配置、权限分层与排障要点整理成一条可读的线索，新成员可以顺着步骤走一遍，老成员可以按栏目直接查。
整套内容按“看懂结构—跑通流程—处理异常—长期维护”四段递进，每一段都刻意保留可核对的关键词与检查项，便于在团队内部对照使用。
- 覆盖范围仓库 · 分支 · 合并请求 · 流水线 · 制品 · 权限
- 适用对象新加入项目的开发者与维护者
- 阅读方式先顺读一遍，再按栏目查阅
- 内容基线以团队现行约定为准，随时更新
内容栏目
-
仓库与目录规划
仓库顶层放什么、文档与脚本各自归位、共享配置如何被多个项目引用，先定下来，后续分支与流水线才不会互相牵连。
-
分支与提交约定
功能分支、修复分支与集成分支的命名方式、合并方向与回收时机，配合提交信息的书写格式，让历史记录可读可追。
-
合并请求与评审
合并请求的描述模板、评审人选择、必须通过的检查项，以及何时允许直接合并，都在这一栏里逐条列出。
-
流水线配置
从构建、测试到打包的各个阶段如何串联，缓存与并行如何取舍，配置改动前需要先在哪个分支验证。
-
制品与记录留存
产物命名、保存时长、下载入口与版本对照方式，保证任何一次产出都能回溯到对应的提交与流水线编号。
-
权限与排障
角色分层、保护规则、密钥与变量管理，以及流水线异常时从日志到配置的排查顺序。
从零跑通一条链路的步骤
-
确认仓库骨架
先看清目录结构：源码、配置、脚本与文档各自的位置是否清晰。把共享的流水线片段集中存放，方便多处引用与统一修改。
-
建立分支并对应任务
从集成分支切出功能分支，命名中带上任务编号或简短描述，一次分支只处理一件事，避免评审时混杂无关改动。
-
本地自检后再提交
提交前运行可本地执行的检查项，提交信息写清改动原因。小而完整的提交比一次大提交更容易定位问题。
-
发起合并请求并等待检查
在描述中交代背景、改动范围与验证方式；等待流水线结果与评审意见，全部通过后再按约定方式合并。
-
观察流水线产出与记录
合并后确认流水线完成、制品已生成，并核对版本号与提交的对应关系；把本次过程中的新约定补回文档。
-
回收分支并整理配置
删除已完成的分支，把复用到的配置片段沉淀下来，供下一个任务直接引用。
环节对照
下表把常见环节的两种做法并列，便于在团队内讨论取舍；具体采用哪一列，以项目实际情况和现有约定为准。
| 环节 | 松散做法 | 规范做法 | 关注点 |
|---|---|---|---|
| 分支命名 | 随意命名，长期不删 | 带任务编号，合并后回收 | 历史可读、便于筛选 |
| 提交信息 | 只写“修改”“更新” | 写清原因与影响范围 | 回溯问题时的线索 |
| 合并请求 | 描述留空，直接合并 | 填写背景与验证方式 | 评审效率与责任清晰 |
| 流水线 | 阶段混杂，缓存缺失 | 阶段分明，缓存可控 | 反馈速度与稳定性 |
| 制品留存 | 版本号手工维护 | 与提交和编号自动对应 | 可追溯、可回退 |
| 权限 | 统一高权限 | 按角色分层并设保护 | 变更安全与误操作防护 |
常见问题
gitlab+cg51 的内容应该从哪里开始读？
建议先看“内容栏目”一栏建立整体印象，再按“从零跑通一条链路的步骤”实际操作一遍。手上有具体问题的读者，可以直接跳到“环节对照”或“常见问题”定位相关段落。
仓库里需要提前准备哪些目录？
通常至少要区分源码、流水线配置、辅助脚本和文档四类位置，并把可复用的配置片段单独存放。目录划分不必复杂，但要让新成员一眼能判断东西该放哪里。
流水线失败时先检查什么？
先看失败阶段与日志末尾的报错行，再核对最近一次配置改动和依赖版本；确认是环境问题还是代码问题后，再决定重跑还是修复。养成先复现、再修改的习惯，能减少反复重跑。
分支命名约定能否与现有习惯兼容？
可以在保留现有前缀的基础上补充任务编号或简短描述，逐步统一。约定以“能被筛选、能被理解”为标准，不必追求形式上的完全一致。
制品和记录需要保存多久？
保存时长取决于交付节奏与回溯需求，建议先明确一个团队内部统一的默认值，再对关键版本单独延长，并在文档中写清规则。
维护要点
- 配置片段集中管理，修改后同步通知使用方，避免各项目各自为政。
- 新增检查项时，先在非关键分支试跑，确认稳定后再推广到主线。
- 合并请求模板与描述要求随团队变化更新，保持评审标准一致。
- 权限调整留痕，涉及保护规则的改动由两人确认后执行。
- 每轮迭代结束回看一次文档，把口头约定落到纸面。