前端 Git 协作规范实战：commit message + 分支管理 + 合并流程，告别冲突与混乱｜工程化与协作规范篇

【Git 协作规范】+【前端工程化与团队协作】：从 commit 规范、分支管理到合并流程，一站式掌握 Git 协作实操，彻底告别混乱提交与高频冲突！

📑 文章目录

[一、开篇：为什么要有 Git 协作规范？](#一、开篇：为什么要有 Git 协作规范？)
[二、Commit Message 规范：写得清楚，用得明白](#二、Commit Message 规范：写得清楚，用得明白)
- [2.1 为什么要规范 commit message？](#2.1 为什么要规范 commit message？)
- [2.2 推荐格式：Conventional Commits](#2.2 推荐格式：Conventional Commits)
- [2.3 常用的 type 及含义](#2.3 常用的 type 及含义)
- [2.4 完整示例](#2.4 完整示例)
- [2.5 常见坑与建议](#2.5 常见坑与建议)
三、分支管理：怎么划分、怎么命名
- [3.1 常见分支类型](#3.1 常见分支类型)
- [3.2 分支命名规范](#3.2 分支命名规范)
- [3.3 分支从哪里拉、合并到哪里](#3.3 分支从哪里拉、合并到哪里)
- [3.4 示例：从开发到合并](#3.4 示例：从开发到合并)
- [3.5 常见坑](#3.5 常见坑)
[四、合并流程：Merge 与 Rebase 怎么选](#四、合并流程：Merge 与 Rebase 怎么选)
- [4.1 Merge 和 Rebase 的区别](#4.1 Merge 和 Rebase 的区别)
- [4.2 选 Merge 还是 Rebase？](#4.2 选 Merge 还是 Rebase？)
- [4.3 合并前同步主分支的两种方式](#4.3 合并前同步主分支的两种方式)
- [4.4 Rebase 使用注意](#4.4 Rebase 使用注意)
五、减少冲突的实战技巧
- [5.1 冲突是怎么来的？](#5.1 冲突是怎么来的？)
- [5.2 预防冲突的做法](#5.2 预防冲突的做法)
- [5.3 解决冲突的步骤](#5.3 解决冲突的步骤)
- [5.4 示例：合并时产生冲突](#5.4 示例：合并时产生冲突)
- [5.5 常用排查命令](#5.5 常用排查命令)
六、常见踩坑与避坑
- [6.1 误删、误提交后怎么办？](#6.1 误删、误提交后怎么办？)
- [6.2 已经 push 的提交想改怎么办？](#6.2 已经 push 的提交想改怎么办？)
- [6.3 合并错分支](#6.3 合并错分支)
- [6.4 如何快速回到「干净」状态](#6.4 如何快速回到「干净」状态)
七、小结：一套可直接落地的实践
[🔍 系列模块导航](#🔍 系列模块导航)
- [📝 工程化与协作规范](#📝 工程化与协作规范)
- [📚 系列总览](#📚 系列总览)

同学们好，我是 Eugene（尤金），一名多年中后台前端开发工程师。

（Eugene 发音 /juːˈdʒiːn/，大家怎么顺口怎么叫就好）

很多前端开发者都会遇到一个瓶颈：

代码能跑，但不够规范；功能能实现，但维护起来特别痛苦；一个人写没问题，一到团队协作就各种混乱、踩坑、返工。

想写出干净、优雅、可维护 的专业代码，靠的不是天赋，而是体系化的规范 + 真实实战经验。

这一系列《前端规范实战》，我会用大白话 + 真实业务场景，不讲玄学、不堆理论，只分享能直接落地的规范、标准与避坑指南。

帮你从「会写代码」真正升级为「会写优质、可维护、团队级别的代码」。

一、开篇：为什么要有 Git 协作规范？

很多人会写 git add、git commit、git push，但一到多人协作就容易出问题：

commit 像「修复 bug」「更新代码」，分支满天飞，合并时到处冲突。

规范的作用不是搞形式主义，而是：

让历史清晰，便于回溯和排错
让合并更可预测，减少冲突
让团队习惯统一，协作成本更低

下面从 commit message 、分支管理 、合并流程 、减少冲突 四个部分，手把手讲清楚怎么选、怎么用、会踩哪些坑。

二、Commit Message 规范：写得清楚，用得明白

2.1 为什么要规范 commit message？

自己 3 个月后能看懂当时在改什么
同事能从提交记录快速理解变更
能配合工具做自动 changelog、自动发版
便于用 git log、git bisect 排查问题

2.2 推荐格式：Conventional Commits

通用格式：

复制代码

<type>(<scope>): <subject>

<body>

<footer>

type：本次提交的类型
scope：影响范围（可选）
subject：简短描述，一句话说清

body 和 footer 一般可选；合并到主干或对外发版时再写详细说明。

2.3 常用的 type 及含义

type	含义	示例
`feat`	新功能	`feat(login): 增加微信扫码登录`
`fix`	修复 bug	`fix(cart): 修复数量为 0 时仍可下单`
`docs`	文档相关	`docs: 更新 README 安装说明`
`style`	代码格式（无逻辑变动）	`style: 统一使用单引号`
`refactor`	重构（不改功能）	`refactor(api): 抽离请求封装函数`
`perf`	性能优化	`perf(list): 虚拟滚动优化长列表`
`test`	测试相关	`test: 补充登录模块单元测试`
`chore`	构建、工具、配置等	`chore: 升级 vite 到 5.x`

可以按团队习惯增删，但建议至少保留：feat、fix、docs、refactor、chore。

2.4 完整示例

bash 复制代码

# 好的写法
git commit -m "feat(order): 订单列表增加筛选功能"
git commit -m "fix(login): 修复 token 过期后未跳转登录页的问题"

# 不好的写法（信息量太低）
git commit -m "修改"
git commit -m "更新代码"
git commit -m "修复 bug"

带 body 的写法：

bash 复制代码

git commit -m "feat(pay): 支持支付宝支付

- 接入支付宝 SDK
- 增加支付结果回调处理
- 更新支付配置说明文档

Closes #123"

2.5 常见坑与建议

坑	建议
subject 过长，换行混乱	subject 控制在 50 字内，避免自动换行
一次 commit 改很多不相关内容	按「单一职责」拆分，一个 commit 做一件事
全是「fix」「update」	用 type 区分功能、修复、文档、配置等
中文乱码	统一使用 UTF-8，确认 `git config` 编码设置

三、分支管理：怎么划分、怎么命名

3.1 常见分支类型

main / master：主分支，生产环境对应代码，只接受合并，不直接开发
develop：开发主分支，日常开发合并到这里
feature/xxx：新功能分支
bugfix/xxx：修 bug 分支
hotfix/xxx：线上紧急修复
release/xxx：发布前准备（版本号、文档等）

可以简化为：main + develop + feature，团队小的时候也够用。

3.2 分支命名规范

推荐格式：<类型>/<简述>-<关联 issue>（issue 可选）

复制代码

feature/user-login
feature/order-filter-123
bugfix/cart-total-error
hotfix/payment-timeout

3.3 分支从哪里拉、合并到哪里

feature 从 develop 拉，开发完成后合并回 develop
bugfix 从 develop 拉（或从 main 拉，视场景而定）
hotfix 从 main 拉，修完后合并回 main 和 develop

简单流程图：

复制代码

main (生产)
  │
  ├── hotfix/xxx  → 合并回 main + develop
  │
develop (开发主分支)
  │
  ├── feature/A
  ├── feature/B
  └── bugfix/xxx

3.4 示例：从开发到合并

bash 复制代码

# 1. 从 develop 拉功能分支
git checkout develop
git pull origin develop
git checkout -b feature/order-filter

# 2. 开发、提交
git add .
git commit -m "feat(order): 订单列表增加筛选功能"
git push origin feature/order-filter

# 3. 在 GitLab/GitHub 创建 Merge Request，合并到 develop
# 4. 合并后删除功能分支（可选）
git checkout develop
git pull origin develop
git branch -d feature/order-filter

3.5 常见坑

长期不合并：功能分支堆太久，合并时冲突非常多
分支过粗：一个分支做多个功能，难以回滚和 code review
忘记同步主分支：开发前不拉最新 develop，合并时冲突加剧

四、合并流程：Merge 与 Rebase 怎么选

4.1 Merge 和 Rebase 的区别

Merge：生成一个新的合并提交，保留分叉历史
Rebase：把当前分支的提交「挪」到目标分支最新提交之后，历史成一条线

4.2 选 Merge 还是 Rebase？

Merge 适合：

合并到公共分支（如 develop、main）
需要保留完整分叉历史
团队对 Git 不太熟，优先稳定

Rebase 适合：

自己本地的 feature 分支整理提交
希望历史简洁、呈线性
团队统一规范、能区分「个人分支」和「公共分支」

约定：

公共分支（main、develop）：用 Merge
个人 feature 分支：可以在合并前用 Rebase 整理，再 Merge 进 develop

4.3 合并前同步主分支的两种方式

方式一：Merge（安全、简单）

bash 复制代码

git checkout feature/order-filter
git fetch origin
git merge origin/develop
# 解决冲突后
git add .
git commit -m "merge: 同步 develop 最新代码"
git push origin feature/order-filter

方式二：Rebase（历史更干净）

bash 复制代码

git checkout feature/order-filter
git fetch origin
git rebase origin/develop
# 若有冲突，按提示解决后：
git add .
git rebase --continue
# 若放弃 rebase：git rebase --abort
git push origin feature/order-filter --force-with-lease

--force-with-lease 比 --force 更安全，会检查远程是否被别人更新过。

4.4 Rebase 使用注意

不要对已经推送到远程的公共分支做 rebase
不要对别人正在使用的分支做 rebase
只在自己的、未分享或刚分享的 feature 分支上用 rebase

五、减少冲突的实战技巧

5.1 冲突是怎么来的？

多人改同一文件的同一区域时，Git 无法自动决定保留哪边，就会产生冲突。

5.2 预防冲突的做法

小步提交、频繁同步
- 每天至少 pull/rebase 一次主分支
- 功能拆小，及时合并
约定「代码归属」
- 大模块专人负责，减少同一文件多人同时大改
- 公共模块改动前在群里说一声
合理拆分文件
- 按功能/模块分文件，而不是一个大文件包所有逻辑

5.3 解决冲突的步骤

知道有冲突：git status 会提示 both modified
打开冲突文件，找冲突标记：

<<<<<<< HEAD
你的修改

别人的修改

origin/develop
手动编辑：删掉标记，保留正确逻辑，必要时两边都保留并整合
标记已解决并继续：

bash 复制代码

git add 冲突文件
git commit   # merge 时
# 或
git rebase --continue  # rebase 时

5.4 示例：合并时产生冲突

bash 复制代码

# 假设你在 feature/order-filter 上开发，develop 已更新
git merge origin/develop
# 输出：CONFLICT (content): Merge conflict in src/views/order/list.vue

打开 list.vue：

html 复制代码

<<<<<<< HEAD
    <el-select v-model="filterForm.status" placeholder="订单状态">
      <el-option label="全部" value="" />
      <el-option label="待支付" value="pending" />
      <el-option label="已完成" value="completed" />
    </el-select>
=======
    <el-input v-model="filterForm.keyword" placeholder="搜索订单号" />
>>>>>>> origin/develop

合理做法是两边的筛选都要保留：

html 复制代码

    <el-input v-model="filterForm.keyword" placeholder="搜索订单号" />
    <el-select v-model="filterForm.status" placeholder="订单状态">
      <el-option label="全部" value="" />
      <el-option label="待支付" value="pending" />
      <el-option label="已完成" value="completed" />
    </el-select>

然后：

bash 复制代码

git add src/views/order/list.vue
git commit -m "merge: 同步 develop，整合订单筛选与搜索"

5.5 常用排查命令

bash 复制代码

git status              # 看哪些文件冲突
git diff                # 看工作区具体改动
git log --oneline -10   # 看最近提交
git merge --abort       # 放弃本次 merge
git rebase --abort      # 放弃本次 rebase

六、常见踩坑与避坑

6.1 误删、误提交后怎么办？

bash 复制代码

# 恢复未 add 的修改
git checkout -- 文件名
# 或
git restore 文件名

# 撤销已 add、未 commit
git reset HEAD 文件名

# 撤销上一次 commit，保留修改
git reset --soft HEAD~1

6.2 已经 push 的提交想改怎么办？

尽量不改公共分支历史
如果是自己的 feature 分支且没人基于它开发，可以 git rebase -i 修改后再 push --force-with-lease
若已经合并到 develop，更稳妥的是再打一个「修正」类的 commit

6.3 合并错分支

bash 复制代码

# 若还未 push
git reset --hard HEAD~1

# 若已 push，先 reset 再强制推送（谨慎，确认无人基于该提交开发）
git reset --hard HEAD~1
git push origin 分支名 --force-with-lease

6.4 如何快速回到「干净」状态

bash 复制代码

git stash
git stash list
git stash pop
git stash drop

七、小结：一套可直接落地的实践

Commit ：用 Conventional Commits，type(scope): subject，一个 commit 做一件事
分支：main/develop + feature/bugfix，命名清晰，从 develop 拉、合并回 develop
合并：公共分支用 Merge，个人分支可在合并前 Rebase 整理历史
冲突：小步提交、勤同步、约定模块归属，出现冲突按「定位 → 编辑 → add → 继续」处理
工具：可用 commitlint、husky 做提交检查，用 GitLab/GitHub MR 做代码评审

按上面这套来做，日常协作会更清晰，冲突会少很多，历史也好查、好排错。

规范的意义不在于多复杂，而在于：大家用同一套规则，协作成本更低，代码更可控。

🔍 系列模块导航

📝 工程化与协作规范

一、《Vite 工程化实战：alias/env/proxy/ 打包配置全解析，统一项目规范避坑｜工程化与协作规范篇》
二、《前端多环境配置规范：dev/test/pre/prod 环境差异与配置，避免生产环境踩坑｜工程化与协作规范篇》

三、《前端 Git 协作规范实战：commit message + 分支管理 + 合并流程，告别冲突与混乱｜工程化与协作规范篇》
四、《ESLint + Prettier 实战：统一前端代码风格，自动修复语法格式问题｜工程化与协作规范篇》
五、《Element Plus/VXE-Table UI 组件库规范：统一用法实战，避开样式冲突与维护混乱｜工程化与协作规范篇》

👉 跟着系列慢慢学，把技术功底扎扎实实地打牢～

📚 系列总览

前端体系化学习完全体：基础 → 规范 → 架构 → 大厂面试

四套系列、百余篇高质量实战文，从入门到进阶，一站式补齐前端核心能力

前端基础实战系列 ：《前端基础实战：JS/TS与Vue体系化扫盲（47 篇完整目录 + 避坑）》
前端规范实战系列 ：《JS/TS/Vue 前端规范实战：从写对到写优，搞定中后台规范落地，打造可维护代码（40 篇全目录）》
前端架构实战系列：聚焦工程化、性能优化、可维护架构、中后台体系设计（持续更新中）
前端大厂面试系列：覆盖高频考点、手写题、项目深挖、简历与面试技巧（规划中）

每个系列完结后，都会整理成一篇完整导航文并附上直达链接，方便大家按顺序、体系化学习。

全套内容持续更新中，敬请期待～

技术成长，从来不是比谁写得快，而是比谁写得稳、规范、可维护。

哪怕每次只吃透一条规范，长期下来，差距会非常明显。

后续我会持续更新前端规范、工程化、可维护代码相关实战干货，帮你告别面条代码、维护噩梦，在开发与面试中更有底气。

觉得有用欢迎 点赞 + 收藏 + 关注，不错过每一篇实战内容。

我是 Eugene，与你一起写规范、写优质代码，我们下篇干货见～

前端 Git 协作规范实战：commit message + 分支管理 + 合并流程，告别冲突与混乱｜工程化与协作规范篇

📑 文章目录

一、开篇：为什么要有 Git 协作规范？

二、Commit Message 规范：写得清楚，用得明白

2.1 为什么要规范 commit message？

2.2 推荐格式：Conventional Commits

2.3 常用的 type 及含义

2.4 完整示例

2.5 常见坑与建议

三、分支管理：怎么划分、怎么命名

3.1 常见分支类型

3.2 分支命名规范

3.3 分支从哪里拉、合并到哪里

3.4 示例：从开发到合并

3.5 常见坑

四、合并流程：Merge 与 Rebase 怎么选

4.1 Merge 和 Rebase 的区别

4.2 选 Merge 还是 Rebase？

4.3 合并前同步主分支的两种方式

4.4 Rebase 使用注意

五、减少冲突的实战技巧

5.1 冲突是怎么来的？

5.2 预防冲突的做法

5.3 解决冲突的步骤

<<<<<<< HEAD 你的修改

5.4 示例：合并时产生冲突

5.5 常用排查命令

六、常见踩坑与避坑

6.1 误删、误提交后怎么办？

6.2 已经 push 的提交想改怎么办？

6.3 合并错分支

6.4 如何快速回到「干净」状态

七、小结：一套可直接落地的实践

🔍 系列模块导航

📝 工程化与协作规范

📚 系列总览

<<<<<<< HEAD
你的修改