GitLab中如何管理分支和合并请求

分支策略选型

选择合适的分支策略，是团队高效协作的基石。市面上主流策略各有侧重，关键在于匹配你的项目节奏和发布需求。

• GitLab Flow（推荐）：这条路径以 main 或 develop 作为持续交付的主干线，变更像流水一样，按环境顺序向下游合并（例如 master → staging → preprod → production）。当需要对外发布时，再启用 production 分支或专门的 release/ 分支。它的逻辑清晰，非常适合大多数追求持续交付的团队。
• Git Flow：这是一套经典的“双主干”模型，长期维护 master 和 develop 分支，并辅以 feature/、release/、hotfix/ 等临时分支。它的规范非常完整，但流程也相对复杂，更适合那些版本发布节奏明确、需要并行维护多个版本的大型项目或组织。
• GitHub Flow：极致简化的代表，通常只有 main 和 feature/ 分支，主张“合并即部署”。这种模式非常适合SaaS类产品或能够随时发布上线的场景。

无论选择哪一种，都可以与 Issue 跟踪系统和环境分支的概念相结合，从而形成一套标准化的协作链路。

分支命名与生命周期

清晰的命名和严格的生命周期管理，能有效避免分支混乱，提升仓库的整洁度。

• 命名约定（示例）：
  • 功能开发：feature/{name} 或 feat_{yymmdd}_{tapdId}_{var}
  • 缺陷修复：bugfix/{name} 或 fix_{yymmdd}_{tapdId}_{var}
  • 版本发布：release/{version}
  • 紧急修复：hotfix/{name}
• 生命周期管理：
  • 长期分支：通常只保留 main/master 和可选的 develop 分支，其余所有分支都应视为临时性质。
  • 及时清理：分支合并后，务必及时删除远程和本地的临时分支。这不仅能避免仓库堆积，更能防止团队成员误用旧分支。
• 环境与权限（可选但强烈建议）：
  • 固定环境分支：可以设立如 test（提测）、dev（联调）等分支，并设置为仅允许“合并入”，禁止直接提交，确保代码来源可控。
  • 主干保护：main/master 分支应仅允许通过合并请求（MR）进入，禁止直接推送。每次成功上线后，记得在 main/master 上打上 Tag，这是版本历史的关键锚点。

合并请求全流程

一次规范的代码合并，远不止点击一下按钮。从本地开发到最终清理，每个环节都关乎代码质量。

• 本地开发
  1. 拉取最新主干：git checkout main && git pull
  2. 创建分支：git checkout -b feature/login
  3. 提交变更：git add . && git commit -m "feat(login): add login"
  4. 推送远端：git push origin feature/login
• 在 GitLab 创建 MR
  • 进入项目 → Merge Requests → New merge request → 选择源分支（如 feature/login）与目标分支（如 develop/main）→ 填写清晰的标题与描述 → 指派审核人（Assignee/Reviewer）→ 提交。
• 代码审查与 CI
  • 评审者通过评论提出修改建议。同时，在 .gitlab-ci.yml 中配置的流水线必须运行通过，这是允许合并的前置条件。
• 合并与清理
  • 点击 Merge 完成合并。建议勾选“合并后删除源分支”以自动清理远端分支。本地清理命令：git branch -d feature/login 与 git push origin --delete feature/login。
• 小技巧
  • 使用 Squash and merge 功能，可以将一个功能分支上的多次提交压缩为一次，让目标分支的提交历史保持清晰整洁。
  • 遇到冲突时，优先在本地基于目标分支进行 rebase 操作，或者创建一个临时分支解决冲突后再合并，这样可以最大程度减少对协作分支的污染。

权限与保护策略

没有规矩，不成方圆。通过权限设置，可以为代码库建立起坚固的质量防线。

• 在 Project → Settings → Repository → Protected Branches 中进行配置：
  • 将 main/master、develop、release/ 等关键分支设置为受保护分支。
  • 角色权限要点：通常，Developer 角色可以创建合并请求，而 Maintainer 角色拥有合并和推送到受保护分支的权限。可以禁止强制推送（force push）和直接推送，强制所有变更都必须经过 MR 流程。
• 利用 Merge Request Approvals（审批规则） 来落实具体的质量门禁，例如“至少需要 N 人评审通过”、“必须所有 CI 流水线成功”、“禁止提交者自己合并自己的请求”等。这些规则保证了每一次变更都可追溯、合规，是团队协作质量的基石。

发布与热修复流程

发布是价值的最终交付，而热修复则是系统的安全网。清晰的流程能确保这两件事都平稳可控。

• 常规发布（环境下行）
  • 特性在 feature/ 分支完成，通过 MR 合并到 develop/main → 创建 MR：main → staging 部署联调 → 稳定后 MR：staging → preprod → 最终 MR：preprod → production。每次上线后，务必在 production/main 上打 Tag。必要时，可以通过 cherry-pick 将修复应用到下游分支。
• 使用 Release 分支（可选）
  • 当项目无法随时发布或需要进行严格的版本化管理时，可以从 develop 拉出 release/{version} 分支，用于发布前的最终准备和回归测试。发布成功后，再将其合并回 main/master 和 develop，并打上版本 Tag。
• 紧急热修复
  • 从 production/main 拉取 hotfix/{name} 分支进行修复 → 修复完成后，合并到 main/master 并打 Tag → 关键一步：将此修复同步合并到 develop（或当前的发布分支），避免在后续开发中遗漏该修复。如果项目采用 release/ 流程，则应先合并到 release/ 分支进行回归，再发布。