【Git 避坑指南】切记不要在 GitLab 解决 daily/dev 冲突！Git 回退 Merge 记录完整方案

【Git 避坑指南】切记不要在 GitLab 解决 daily/dev 冲突Git 回退 Merge 记录完整方案前言在团队协作开发中daily/dev分支是开发测试分支master是生产分支分支权限与合并规范直接决定线上代码安全性。千万不要在 GitLab 网页端直接解决 daily/dev 分支的冲突否则会导致把daily无关代码合并进自己的功能分支上线时将测试/无效代码带入生产代码污染、线上风险、回退困难本文总结 *正确解决冲突方案 错误 Merge 回退方案 团队规范红线一、自己的分支只有自己修改提交却提示必须 pull现象本地新建分支、独自开发提交时报需要先拉取远程更新pull根本原因从GitLab 远程新建分支后VS Code 本地未fetch到该远程分支而是本地切到旧的master直接新建同名本地分支导致本地分支 ≠ 远程分支后期自动关联后出现版本分叉 → 必须 pull 才能同步正确切换远程分支方案推荐# 先抓取所有远程分支最标准、最安全gitfetch# 再从远程分支创建本地分支gitcheckout 分支名错误方案导致冲突/pull 问题不要直接在本地旧 master 上新建同名分支二、【团队红线】切记不要在 GitLab 解决 daily/dev 冲突为什么绝对不能做在 GitLab 网页点Resolve conflicts解决 daily → 你的分支 冲突时GitLab 会自动把 daily 分支合并到你的功能分支后果你的分支 你的代码 别人的 daily 代码合并到 master 时 把测试/未上线/无效代码带上生产线上故障、代码污染、难以回溯唯一允许在 GitLab 解决冲突的场景合并到 master / main 时master 是保护分支冲突解决是安全的三、团队标准正确解决 Merge 冲突的 2 种方案所有冲突必须在本地解决禁止网页端解决 daily 冲突。方案1以 daily 为基准推荐复杂冲突适用大量改动、需要保留双方代码、逻辑复杂从最新 daily 拉一个中转分支将你的功能分支合并到中转分支本地手动解决冲突提交中转分支提交 MR 合并回 daily合并完成后删除源分支方案2以自己分支为基准简单冲突适用少量文件、冲突明确本地拉取最新 daily本地 merge 到自己分支本地解决冲突push 到远程提交 MR合并完成后删除源分支统一规范无论哪种方案合并后都必须删除源分支Delete source branch四、失误了已在 GitLab 把 daily 合并进自己分支怎么救紧急方案 Agit revert 撤回 Merge推荐# 1. 找到错误的 Merge commit IDgitlog# 2. 执行 revert 撤回这次合并-m 1 固定写法gitrevert-m1你的Merge提交ID# 3. 提交并推送gitadd.gitcommit-mrevert: 撤销错误合并 daily 的代码gitpush✅ 优点安全、标准、可回溯❌ 缺点保留历史记录适合大多数场景终极方案 B彻底清除 Merge 痕迹最干净适用错误合并后又提交了新代码需要彻底清理在错误 Merge 记录之前新建一个干净中转分支将你正确的业务提交cherry-pick 到中转分支使用对比工具Beyond Compare全量比对文件将干净代码覆盖回工作分支提交、推送到远程再合并到 master✅ 优点历史完全干净❌ 缺点操作稍复杂五、解决代码冲突【团队红线·必须遵守】禁止直接采用“传入的所有更改”必须逐行检查该保留保留、该合并合并。遇到他人代码不确定 → 必须找原作者确认禁止凭感觉覆盖他人代码。解决完冲突提交前必须自我审查 diff避免把无关代码、注释、调试代码提交。master 冲突必须谨慎生产分支无小事冲突必须双人核对。六、常用 Git 命令沉淀便于收藏# 查看远程仓库地址gitremote-v# 重新设置远程仓库地址gitremote set-url origin 新地址# 拉取所有远程分支gitfetch# 撤销合并关键救命命令gitrevert-m1Merge提交ID七、总结最核心 3 句话daily/dev 冲突绝对不在 GitLab 解决冲突必须本地解决两种方案以 daily 基准 / 以自己分支基准误合并 daily → 使用git revert -m 1快速回退