Ubuntu 下使用 GitLab 的分支管理实操指南
一 基础准备
- 安装与配置 Git：在 Ubuntu 上安装 Git，配置全局用户名与邮箱，便于提交记录归属。
- 命令：sudo apt update && sudo apt install -y git
- 配置：git config --global user.name “Your Name”；git config --global user.email “you@example.com”
- 克隆仓库与 SSH：使用 SSH 克隆项目，避免频繁输入账号密码；将本地公钥添加到 GitLab 个人 SSH Keys。
- 命令：git clone git@gitlab.com:namespace/project.git
- 生成密钥：ssh-keygen -t rsa -b 4096 -C “you@example.com”，将 ~/.ssh/id_rsa.pub 内容粘贴到 GitLab。
二 分支策略选择与命名规范
- 常用策略对比与适用场景
| 策略 |
核心分支 |
适用场景 |
优点 |
注意点 |
| Git Flow |
main/master、develop、feature/、release/、hotfix/* |
版本节奏明确、并行发布多版本 |
阶段清晰、便于发布与回滚 |
分支多、维护成本略高 |
| GitHub Flow |
main + 短生命周期 feature/ |
持续交付、小步快跑 |
简单、部署频繁 |
需强自动化与完备测试 |
| GitLab Flow（上游优先 + 环境分支） |
main、staging、production |
环境区分明确、渐进发布 |
与 CI/CD 贴合、环境一致 |
需规范环境与部署准入 |
- 推荐命名规范
- 主分支：main/master（稳定生产基线）
- 功能分支：feature/功能名 或 feature/任务编号-简短描述
- 修复分支：fix/问题编号-描述
- 紧急修复：hotfix/问题编号-描述
- 发布分支：release/版本号（如 release/1.2.0）
- 提交信息：采用约定式（如 feat/fix/docs 前缀），便于生成变更日志与自动化。
三 日常分支操作命令清单
- 创建与推送
- 本地创建并切换：git checkout -b feature/user-auth main
- 推送到远端并设置上游：git push -u origin feature/user-auth
- 同步与更新
- 拉取远端更新：git pull --rebase origin main（建议 rebase 保持线性历史）
- 合并方式（按团队规范选择其一或多种）
- 仅快进：git merge --ff-only feature/user-auth
- 保留合并提交：git merge --no-ff feature/user-auth
- 变基后合并：git rebase main → git checkout main → git merge feature/user-auth
- 删除分支
- 删除本地：git branch -d feature/user-auth
- 删除远端：git push origin --delete feature/user-auth
- 查看与差异
- 图形化日志：git log --oneline --graph --decorate --all
- 分支差异：git diff main…feature/user-auth
- 冲突处理
- 命令行：合并冲突后编辑文件 → git add → git commit
- Web IDE：在 Merge Request 中点击 Resolve conflicts 在线解决并提交。
四 GitLab 平台侧配置与权限
- 分支保护规则
- 路径：项目 → Settings → Repository → Protected branches
- 对 main/master 禁止直接推送与强制推送；仅允许通过 Merge Request 合并
- 配置 Allowed to push / Allowed to merge 角色（如 Maintainers 可合并，Developers 可推送特定分支）
- 启用 Require code owner approval、可选 Require approval from Code Owners、设置 Allowed to merge 的最小人数
- 合并请求与代码审查
- 创建 Merge Request（MR） 从功能分支到目标分支（如 main 或 develop）
- 指定 Reviewer/Assignee，开启 WIP 防止提前合并，要求通过 CI 流水线
- 合并前解决冲突、完成评审与讨论，合并后删除源分支（可勾选自动删除）
- 环境与部署准入
- 使用 GitLab CI/CD 定义多阶段流水线（如 build → test → deploy-staging → deploy-prod）
- 在 MR 或流水线中设置环境准入与手动批准（如生产部署 when: manual）
- 保护关键环境分支（如 staging、production）仅允许特定角色部署。
五 规范落地与自动化建议
- 分支生命周期与清理
- 将 feature/、release/、hotfix/* 视为临时分支，合并后及时删除远端与本地
- 定期清理已合并或长期未活跃分支，保持仓库整洁（可结合脚本或 API 批量清理）
- 多仓库与规模化治理
- 统一团队的 命名规范、保护策略、评审与准入门槛
- 在 项目/组级 复用 .gitlab-ci.yml 模板与保护规则，减少维护成本
- 示例 CI 片段（按分支控制阶段）
- stages: [build, test, deploy]
- build: script: ./gradlew build
- test: script: ./gradlew test
- deploy_staging: script: ./deploy.sh staging
only: [main]
environment: staging
- deploy_prod: script: ./deploy.sh production
only: [main]
when: manual
environment: production
- 安全与合规
- 在 Settings → CI/CD → Variables 配置敏感变量（如 API_KEY、DB_PASSWORD），并在 CI 中使用，避免硬编码
- 定期审计 Runner 状态、权限与流水线执行结果，确保交付稳定。
